WO2018235379A1 - サービス情報提供システムおよび制御方法 - Google Patents

サービス情報提供システムおよび制御方法 Download PDF

Info

Publication number
WO2018235379A1
WO2018235379A1 PCT/JP2018/013753 JP2018013753W WO2018235379A1 WO 2018235379 A1 WO2018235379 A1 WO 2018235379A1 JP 2018013753 W JP2018013753 W JP 2018013753W WO 2018235379 A1 WO2018235379 A1 WO 2018235379A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
user
information
compatibility
users
Prior art date
Application number
PCT/JP2018/013753
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 US16/620,971 priority Critical patent/US20200202474A1/en
Publication of WO2018235379A1 publication Critical patent/WO2018235379A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06315—Needs-based resource requirements planning or analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • G06Q50/43—Business processes related to the sharing of vehicles, e.g. car sharing
    • G06Q50/47—Passenger ride requests, e.g. ride-hailing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q2240/00—Transportation facility access, e.g. fares, tolls or parking

Definitions

  • the present disclosure relates to a service information providing system and control method.
  • the service may be enjoyable or unpleasant depending on not only the content of the service but also the compatibility with the other party.
  • Patent Document 1 discloses a shared vehicle search system capable of searching for a customer compatible with a user.
  • people with similar attributes are recommended as carpoolers. Specifically, whether gender, age, hobbies, family structure match or not, purchase behavior (time zone of visit or items purchased) are the same, and geographical conditions (route to destination) Matching is performed based on whether they are close or not.
  • the service which determines the community to participate is disclosed based on the user relationship information showing the relationship between several users.
  • the user-related information includes subjective evaluations of the plurality of users with respect to each other (e.g., evaluation of the other's character, affinity with oneself, accuracy of the other's information, etc.).
  • the score of each community is calculated based on the user relationship information, and a participating community suited to the user is recommended.
  • Patent Document 3 discloses a combined taxi system in which a taxi is allocated to a patient who wishes to be connected when returning home.
  • patients wishing to be joined who belong to the same time zone in which the in-hospital processing completion time belongs and belong to the same place of residence are divided according to the boarding capacity and set as the same patient group for taxis.
  • an airborne disease eg, influenza
  • a service information providing system and control method capable of responding to various service requests based on affinity information of shared service users acquired without burdening users and shared service providers. suggest.
  • the system in a service information providing system operated by a service provider who provides services to a plurality of users sharing the same space in the same time zone, the system can be obtained by sensing a plurality of users using the service.
  • Storage unit for storing compatibility information indicating compatibility between a plurality of users generated based on the sensor data, a communication unit for receiving a service request from the user, and the user and others already stored in the storage unit
  • a control unit configured to control service provision information according to the service request to be provided via the communication unit based on affinity information with a user.
  • the service information providing server operated by a service provider who provides a service to a plurality of users sharing the same space in the same time zone is provided with compatibility information between the plurality of users using the service.
  • a service information providing system a storage unit for storing compatibility information indicating compatibility between a plurality of users generated based on sensor data obtained by sensing a plurality of users in use of the service;
  • a communication unit for receiving, via the user, information corresponding to a service request from the user, and information identifying another user who enjoys the service with the user, and the user already stored in the storage unit On the basis of compatibility information with other users, the user and the other users who enjoy the service together
  • the compatibility information, and a control unit that controls to provide to the service information providing server via the communication unit proposes a service information providing system.
  • a processor communicates a service request from a user
  • the user already stored in the storage unit storing compatibility information indicating compatibility between a plurality of users, which is generated based on sensor data obtained by receiving by the unit and sensing a plurality of users who are using the service
  • the service information providing server operated by a service provider who provides a service to a plurality of users sharing the same space in the same time zone is provided with compatibility information between the plurality of users using the service.
  • the processor stores compatibility information indicating compatibility between a plurality of users, which is generated based on sensor data obtained by sensing a plurality of users using the service, in a storage unit.
  • FIG. 1 is a diagram for describing an overview of an information processing system according to an embodiment of the present disclosure.
  • the information processing system service information providing system
  • the user next It is possible to match partners that are compatible when using the same or different sharing services (e.g. ride sharing).
  • the sharing service is a service in which a plurality of users share and use the same space in the same time zone, and in recent years, for example, a share house in which a plurality of users share a house and a ride share in which a passenger is shared ing.
  • the sharing service in this specification also includes the case where time and space are shared with a large number of people (people who are strangers) such as trains, buses, movie theaters, and theaters.
  • space mentioned here includes not only the real world but also the virtual world (VR: Virtual Reality).
  • affinity information is generated based on sensing data obtained by sensing a user who is using the service at the first service utilization, and affinity generated at the second service utilization. Information can be used to match compatible partners.
  • compatibility information will be described in detail below, for example, the characteristics etc. of each user are categorized based on sensing data obtained by sensing the user in use of the service at the time of first service use. Generate compatibility between personality types as compatibility information. Then, at the second use of the service, based on the generated compatibility information, a person of a personality type that is compatible with the personality type of the user may be recommended as a sharing partner.
  • affinity matching By performing affinity matching based on the typified personality type, it is also possible to estimate affinity between users who have never been together before, and it is possible to respond to service requests in various sharing services.
  • the information processing system can perform affinity matching based on a personality type (also referred to as personality type), there is no need to consider a combination of many users, which places a burden on the shared service provider. Absent.
  • FIG. 2 is a diagram showing an example of the entire configuration of the information processing system according to the present embodiment.
  • the information processing system includes a user terminal 1, a compatibility management server 2, and a service providing server 3.
  • the user terminal 1 is an information communication terminal used by each user, and for example, a smartphone, a mobile phone, a tablet terminal, a PC (personal computer), a wearable device (smart eyeglass, smart band, smart watch, smart neck speaker, etc.) , A music reproduction device, a game device, etc. are assumed.
  • the user connects to the service providing server 3 from the user terminal 1, transmits a service request, and receives information for providing a service or enjoying a service.
  • the affinity management server 2 analyzes the sensing data of each user at the time of using the service to generate and manage affinity information, and provides the affinity information in response to a request from the service providing server 3.
  • the service providing server 3 In response to the service request from the user terminal 1, the service providing server 3 provides the sharing service and presents information for providing the sharing service to the user.
  • the service providing server 3 corresponds to each sharing service.
  • the service providing server 3A is a ride share service providing server
  • the service providing server 3B is a share house service providing server
  • the service providing server 3C is a movie reservation server It may be a service providing server.
  • the service providing server 3 when providing the sharing service, recommends the other party having a good affinity to the user or takes into consideration the affinity degree of the other party in consideration of the affinity information acquired from the affinity management server 2. It is possible to present to the user.
  • the service providing server 3 senses the user at the time of using the service with the sensor group 4 and transmits the sensing data or the analysis result obtained by analyzing the sensing data to the affinity management server 2.
  • the sensor group 4 may be provided, for example, in a space for sharing, or the user terminal 1 may be used as the sensor group 4.
  • FIG. 3 is a block diagram showing an example of the configuration of the user terminal 1 according to the present embodiment.
  • the user terminal 1 includes a control unit 10, a communication unit 11, an input unit 12, an output unit 13, and a storage unit 14.
  • the control unit 10 functions as an arithmetic processing unit and a control unit, and controls the overall operation in the user terminal 1 according to various programs.
  • the control unit 10 is realized by, for example, an electronic circuit such as a central processing unit (CPU) or a microprocessor.
  • the control unit 10 may include a ROM (Read Only Memory) that stores programs to be used, operation parameters, and the like, and a RAM (Random Access Memory) that temporarily stores parameters and the like that appropriately change.
  • ROM Read Only Memory
  • RAM Random Access Memory
  • control unit 10 performs control to transmit a service request for requesting use of a predetermined share service from the communication unit 11 to the service providing server 3 according to an operation input by the user. Also, the control unit 10 controls the service information received from the service providing server 3 to be output from the output unit 13 and presented to the user.
  • the communication unit 11 is connected to an external device by wire or wirelessly, and transmits and receives data to and from the external device.
  • the communication unit 11 is connected to the service providing server 3 via the network to transmit and receive data.
  • the communication unit 11 is, for example, a wired / wireless LAN (Local Area Network), Wi-Fi (registered trademark), a mobile communication network (LTE (Long Term Evolution), 3G (third generation mobile communication system)) Communicate and connect with the network 3 by the like.
  • the input unit 12 has a function of detecting input information to the user terminal 1 and outputting the input information to the control unit 10.
  • the input unit 12 can be realized by an operation input unit or a voice input unit.
  • the operation input unit receives an operation instruction from the user, and outputs the content of the operation to the control unit 10.
  • the operation input unit may be a touch sensor, a pressure sensor, or a proximity sensor.
  • the operation input unit may be a physical configuration such as a button, a switch, and a lever.
  • the audio input unit is realized by a microphone, a microphone amplifier unit for amplifying and processing an audio signal obtained by the microphone, and an A / D converter for digital conversion to an audio signal, and the audio signal is output to the control unit 10 Do.
  • the output unit 13 has a function of presenting the information output from the control unit 10 to the user.
  • the output unit 13 is realized by a display unit, a projection unit, an audio output unit, a vibration unit, and the like.
  • the display unit is a display device that outputs a screen or the like for inputting a service request.
  • the display unit may be, for example, a display device such as a liquid crystal display (LCD) or an organic electro luminescence (EL) display.
  • the audio output unit has a speaker for reproducing an audio signal and an amplifier circuit for the speaker.
  • the storage unit 14 is realized by a ROM (Read Only Memory) that stores a program used for processing of the control unit 10 and calculation parameters and the like, and a RAM (Random Access Memory) that temporarily stores parameters and the like that change appropriately.
  • ROM Read Only Memory
  • RAM Random Access Memory
  • the configuration of the user terminal 1 according to the present embodiment has been specifically described above.
  • the configuration of the user terminal 1 is not limited to the example shown in FIG. 3.
  • a sensor acceleration sensor, gyro sensor, geomagnetic sensor, position positioning unit, living body sensor, environment sensor, etc.
  • the user terminal 1 transmits the sensor data acquired by the sensor to the service providing server 3.
  • FIG. 4 is a block diagram showing an example of the configuration of the affinity management server 2 according to the present embodiment.
  • the affinity management server 2 includes a control unit 20, a communication unit 21, and a storage unit 22.
  • Control unit 20 The control unit 20 functions as an arithmetic processing unit and a control unit, and controls the overall operation in the affinity management server 2 according to various programs.
  • the control unit 20 is realized by, for example, an electronic circuit such as a central processing unit (CPU) or a microprocessor.
  • the control unit 20 may also include a ROM (Read Only Memory) that stores programs to be used, operation parameters, and the like, and a RAM (Random Access Memory) that temporarily stores parameters and the like that change appropriately.
  • ROM Read Only Memory
  • RAM Random Access Memory
  • the control unit 20 also functions as the compatibility estimation unit 201 and the matching unit 202.
  • the affinity estimation unit 201 estimates affinity between users based on sensor data of each user sensed at the time of using the service.
  • sensor data for example, a face image picked up by a camera, voice collected by a microphone, biometric sensor data (pulse, heart rate, sweating, breathing, etc.) detected by a biometric sensor may be used.
  • the affinity estimation unit 201 analyzes these sensor data, and shares information based on the user's expression (such as the duration of a smile), the speech time (such as whether the speech is exciting), and the heart rate (such as whether it is a resting state). Calculate the degree of compatibility with The calculated compatibility degree is accumulated in the compatibility information DB 222 together with the compatibility ID, the user ID (principal), and the other user ID.
  • the affinity estimation unit 201 can also calculate the affinity degree for each character type. For example, it is also possible to determine the personality type of each user based on a questionnaire or sensor data, and to calculate the degree of affinity between personality types based on affinity information between users. This also makes it possible to estimate the degree of compatibility with other users who have not been shared in the past.
  • the matching unit 202 performs matching of a sharing user (sharing service) that is compatible with a specific user, based on the compatibility information stored in the compatibility information DB 222.
  • the control unit 20 may return, to the service providing server 3, compatibility information between a specific user and one or more other users, in addition to the matching result by the matching unit 202.
  • the communication unit 21 is connected to an external device by wire or wirelessly, and transmits and receives data to and from the external device.
  • the communication unit 21 is connected to the service providing server 3 via a network to transmit and receive data.
  • the communication unit 21 communicates with an external device through, for example, a wired / wireless LAN (Local Area Network), Wi-Fi (Wireless Fidelity, registered trademark), or the like.
  • the storage unit 22 is realized by a ROM that stores programs used for processing of the control unit 20, calculation parameters, and the like, and a RAM that temporarily stores parameters and the like that change appropriately.
  • the storage unit 22 according to the present embodiment stores a user information DB (database) 221 and a compatibility information DB 222.
  • the user information DB 221 stores user information.
  • the user information includes, for example, a user ID, a name, and compatibility information (here, compatibility ID indicating compatibility information).
  • the compatibility information is stored in the compatibility information DB 222.
  • the affinity information is linked to the affinity ID, and includes a user ID, a partner user ID, and the affinity degree.
  • compatibility information between users includes the compatibility from one user and the compatibility from the other user. For example, as “compatibility information between user A and user B”, “degree of compatibility with user B viewed from user A” and “degree of compatibility with user A viewed from user B” are calculated.
  • the configuration of the affinity management server 2 according to the present embodiment has been specifically described above.
  • the configuration of the affinity management server 2 shown in FIG. 4 is an example, and the present embodiment is not limited to this.
  • an external device may have at least a part of the configuration of the affinity management server 2, or an information processing terminal (a user terminal 1 has at least a part of each function of the control unit 20).
  • it may be realized by a so-called edge server or the like, or the service providing server 3.
  • edge server or the like or the service providing server 3.
  • the affinity management server 2 may return affinity information of a specific user in response to a request from the service providing server 3, and the service providing server 3 may perform matching of a close sharer.
  • FIG. 5 is a block diagram showing an example of the configuration of the service providing server 3 according to the present embodiment.
  • the service providing server 3 includes a control unit 30, a communication unit 31, and a storage unit 32.
  • Control unit 30 The control unit 30 functions as an arithmetic processing unit and a control unit, and controls the overall operation in the service providing server 3 according to various programs.
  • the control unit 30 is realized by, for example, an electronic circuit such as a central processing unit (CPU) or a microprocessor.
  • the control unit 30 may include a ROM (Read Only Memory) that stores programs to be used, operation parameters, and the like, and a RAM (Random Access Memory) that temporarily stores parameters and the like that change appropriately.
  • ROM Read Only Memory
  • RAM Random Access Memory
  • the control unit 30 also functions as the service provision control unit 301.
  • the service provision control unit 301 performs various operation processing related to provision of the sharing service. For example, in the case of the ride sharing service, in accordance with a request from the user, the user is presented with the date and time of traveling and the travel route of vehicles that can be shared. Also, in the case of a share house service, the candidate of a shareable house is presented. In addition, when the service provision control unit 301 according to the present embodiment presents to the user car and house candidates to be shared, the affinity between the user and the sharer is also presented based on the affinity information acquired from the affinity management server 2 It is possible.
  • the service provision control unit 301 may automatically distribute the sharer so as to share in a relatively compatible combination based on the compatibility information so that a comfortable share can be performed without the user's selection. .
  • control unit 30 receives, from the sensor group 4 via the communication unit 31, sensor data obtained by sensing the user who is using the service by the sensor group 4 (see FIG. 2), and links it with the user ID. And sends it to the compatibility management server 2.
  • the sensor group 4 is provided, for example, in a shared space (in a car, in a house, etc.), and more specifically, a camera, a position positioning unit, a microphone, a biological sensor, etc. are assumed.
  • the camera photoelectrically converts the imaging light obtained by the lens system including the imaging lens, the aperture, the zoom lens, the focus lens, etc., the drive system for performing the focusing operation and the zooming operation on the lens system, and the lens system. It has a solid-state image sensor array etc. which generate an image pick-up signal.
  • the solid-state imaging device array may be realized by, for example, a charge coupled device (CCD) sensor array or a complementary metal oxide semiconductor (CMOS) sensor array.
  • the position measurement unit has a function of detecting the current position of a place (for example, a car) where the sensor group 4 is provided based on an external acquisition signal.
  • the position positioning unit is realized by a GPS (Global Positioning System) positioning unit, receives radio waves from GPS satellites, and detects the position where the location is present.
  • the positioning unit detects the position by, for example, transmission / reception with Wi-Fi (registered trademark), Bluetooth (registered trademark), mobile phone, PHS, smart phone, etc. other than GPS, or near distance communication, etc. May be
  • the biometric sensor is a detection unit that detects user's biometric information, and is realized by, for example, a temperature sensor, a vein sensor, a pulse sensor, a heart rate sensor, a sweat sensor, an electroencephalogram sensor, or the like.
  • the communication unit 31 connects to an external device by wire or wirelessly, and transmits and receives data to and from the external device.
  • the communication unit 31 is connected to the affinity management server 2 via the network to transmit and receive data.
  • the communication unit 31 communicates with an external device through, for example, a wired / wireless LAN (Local Area Network), Wi-Fi (Wireless Fidelity, registered trademark), or the like.
  • the storage unit 32 is realized by a ROM that stores a program used for processing of the control unit 30, a calculation parameter, and the like, and a RAM that temporarily stores parameters and the like that change appropriately.
  • the storage unit 32 according to the present embodiment stores the service information DB 321.
  • the service information includes information used to provide the sharing service. For example, in the case of ride share, information on a car (car ID, status (in service / empty), current location, destination, estimated arrival time, etc.) and information on requests from each user (request ID, user ID, request time, Your current location, your destination, etc. are stored.
  • the configuration of the service providing server 3 according to the present embodiment has been specifically described above.
  • the configuration of the service providing server 3 shown in FIG. 5 is an example, and the present embodiment is not limited to this.
  • an external device may have at least a part of the configuration of the service providing server 3, or an information processing terminal (a user terminal 1 or a communication distance is relatively close to the user terminal 1)
  • it may be realized by a so-called edge server or the like.
  • edge server As described above, by appropriately distributing each configuration of the service providing server 3, it is possible to improve real-time performance, reduce processing load, and further secure security.
  • FIG. 6 is a sequence diagram showing operation processing of the information processing system according to the present embodiment.
  • the user terminal 1 makes a service request to the service providing server 3 providing the share service that the user wants to use (step S1).
  • the service providing server 3 matches the compatibility request including at least the ID of the other user who is the sharer candidate of the share service requested by the user and the user in response to the request. (Step S2).
  • the affinity management server 2 performs affinity matching between the requested users (step S3), and sends affinity information to the service providing server 3 as a matching result (step S4).
  • the service providing server 3 transmits service providing information based on the matching result to the user terminal 1 (step S5).
  • the service provision information includes at least compatibility information with the sharer.
  • a service schedule is used as service providing information such that the same car is not shared in the same time zone as other users estimated to be relatively incompatible. It is generated and transmitted to the user terminal 1.
  • the user terminal 1 displays the received service provision information and presents it to the user (step S6), and when the presented service is selected by the user (step S7), the service provision is started (steps S8 and S9). ).
  • the service provision is started (steps S8 and S9). ).
  • the user is notified of the boarding time and the boarding point, and a predetermined car is notified of information about the user.
  • sensor data obtained by sensing the user using the service with the sensor group 4 is acquired (step S10), and the sensor data is transmitted to the compatibility management server 2 (step S11).
  • the affinity management server 2 calculates the affinity degree between the users based on the received sensor data, associates it with the user ID and the like, and accumulates it as affinity information (step S12). At this time, the affinity management server 2 may estimate the personality type of each user, and accumulate affinity information linked to the personality type as the degree of affinity between personality types. The accumulated affinity information can be used in the next affinity matching.
  • compatibility matching with the potential sharer candidate is performed using compatibility information obtained by analyzing sensor data sensed during past share service utilization according to the service request. It is possible to provide more comfortable share service.
  • step S106 when the affinity management server 2 receives an affinity request from the service providing server 3 (step S103 / Yes), compatibility between the users specified in the affinity request is based on the stored affinity information. Matching is performed (step S106).
  • the affinity management server 2 sends back the result of affinity matching to the service providing server 3 (step S109).
  • step S115 when sensor data obtained by sensing a user who is using a service is received from the service providing server 3 (step S112 / Yes), the affinity estimation unit 201 of the affinity management server 2 The degree of compatibility is calculated (step S115).
  • the affinity estimation unit 201 estimates the personality type of each user (step S118), and calculates the affinity degree between personality types by referring to the affinity degree between the individuals (step S121). Then, the compatibility estimation unit 201 accumulates the calculated degrees of compatibility as compatibility information in the compatibility information DB 222 (step S124). Specifically, the affinity estimation unit 201 links the degree of affinity between individuals to a user ID and accumulates it, and associates the degree of affinity between personality types to a personality type and accumulates it.
  • the affinity management server 2 can repeat the affinity matching process shown in FIG. 7 and the affinity degree calculation process shown in FIG. 8, respectively, and perform affinity matching using the affinity degree and the accumulated affinity degree.
  • the basic configuration and operation processing according to the present embodiment are as shown in FIG. 2 to FIG. 8, so the characteristic configuration and operation processing of the present embodiment will be described here.
  • FIG. 9 is a flowchart showing a matching process in consideration of affinity information according to the present embodiment.
  • the service providing server 3 performs a normal matching process according to the request (step S203).
  • the request includes “user ID, time, current location of user, and destination”, and the service providing server 3 refers to the service information stored in the service information DB 321 and request information from other users, List routes for shared vehicles.
  • the service information accumulated in the service information DB 321 is shown in the following Tables 1 and 2.
  • the service information includes information on a ride sharing car and information on a ride sharing request.
  • the information on a car for ride sharing includes, for each car ID, a state of being in service or an empty car, a current location, and a destination and an estimated arrival time when the state is in service. Further, the information on the request includes, for each request ID, a user ID, time, current location, and destination.
  • the service providing server 3 may calculate the toll of each route, the boarding time, the expected getting-off time, and the number of passengers along with the list of the routes.
  • an example of the listed routes is shown in FIG.
  • the example shown in FIG. 10 is, for example, a route listed up when there is a request from the user U2.
  • route 1 is a route on which user U1, user U2 and user U3 ride
  • route 2 is a route on which user U2, user U3 and user U4 ride
  • route 3 is user U2 and user U2. It is a route on which the user U3 rides.
  • the getting-in position and the getting-off position of each user are shown.
  • a selection screen 50 as shown in FIG. 11 is displayed on the user terminal 1.
  • the charge for each route, the boarding time, the expected getting-off time, the number of people joining, the determination button, and the cancel button are displayed.
  • the user (U2) selected an arbitrary route based on such information.
  • a selection screen 51 is presented in which the degree of compatibility with the passenger is also presented for each route.
  • the user can select a route in consideration of the degree of compatibility with the passenger who determines whether or not the ride sharing can be performed comfortably, as well as the fare, the time, and the number of passengers.
  • the service providing server 3 acquires, from the affinity management server 2, the degree of compatibility between the user and each passenger on each route in order to calculate the degree of compatibility for each route (each car).
  • the service providing server 3 selects a passenger of one route (for example, in the case of route 1, "user U1, user U2, and user U3") (step S206).
  • the selected passenger ID is included in the compatibility request and transmitted to the compatibility management server 2.
  • the compatibility management server 2 determines whether the compatibility information between the requested fellow passengers has been stored in the compatibility information DB 222 (step S209). In the case of the accumulation, it is possible to use the degree of compatibility when the same power is taken in the past.
  • the affinity management server 2 refers to the user information stored in the user information DB 221 based on the user ID, and determines whether compatibility information between the requested fellow passengers exists.
  • an example of user information stored in the user information DB 221 is shown in Table 3 below.
  • the user information includes user ID, name, personality type, and compatibility information.
  • compatibility information with other users who have rided in the past is described as a list of compatibility IDs for each other user who rides. For example, in Table 3 above, it can be seen that the user U1 rides with the user U2 once and with the user U6 twice.
  • the affinity management server 2 acquires the affinity degree between the sharer individuals from the affinity information DB 222 based on the affinity ID, and sends it back to the service providing server 3 (step S212).
  • the affinity management server 2 acquires the affinity degree based on the personality type of the sharer, since it has never been ride in the past, and the service providing server Reply to 3 (step S215).
  • the "compatibility information" stored in the compatibility information DB 222 includes compatibility information between individuals and compatibility information between character types.
  • Table 4 below shows an example of compatibility information between individuals.
  • the affinity information between individuals includes affinity ID, date and time (use date and time of sharing service, etc.), user ID (principal), user ID of sharer (other party), and calculated affinity. Since the compatibility with the other is not necessarily symmetrical, compatibility information from both sides is accumulated respectively. For example, when the user U1 and the user U2 share a ride, it can be seen that the compatibility degree with the user U2 of the user U1 is "0.8" and it is enjoyed suddenly, but the compatibility degree with the user U1 of the user U2 with the user U1 is "0.1" Show that it was uncomfortable.
  • the affinity management server 2 may obtain the latest data with priority by referring to the date and time information.
  • compatibility information between character types is used when acquiring compatibility with a partner who has never been raised in the past, and indicates the standard compatibility degree of each character type with respect to a certain character type.
  • Table 5 shows an example of compatibility information between character types. Although the details of the character types will be described later, for example, the degree of compatibility between four character types (00, 01, 10, 11) is described, and these are corrected (updated) based on the interpersonal compatibility information. It is also good.
  • the service providing server 3 matches each route in consideration of the degree of affinity.
  • the result is output (step S221).
  • the service providing server 3 may average the degrees of compatibility of all the passengers (partners to share) for each route, and may present the degrees of compatibility as shown in FIG. 12 for each route.
  • the matching management server 2 may calculate the matching result for each route in consideration of the degree of compatibility.
  • the passengers are the user U1 and the user U3.
  • the degree of compatibility of the user U2 with the user U1 is "0.1".
  • the compatibility with the user U3 of the user U2 does not exist in the compatibility information of Table 4, it is estimated based on the character type. For example, when the character type of the user U2 is "01" and the character type of the user U3 is "11", referring to Table 5 above, the affinity of the user U2 with the user U3 is "0.3". I understand.
  • the affinity is calculated only from the combination with the passenger as an example, but even if the affinity is low, if the equal distance is short (that is, if the equivalence time is short), It is estimated that the discomfort is reduced than when the distance is long.
  • weighting by distance may be performed to calculate the degree of compatibility.
  • the compatibility degree of the route 3 is referred to as "0.3".
  • the calculation method according to the present embodiment is not limited to this, for example, a method of performing weighting according to gender such as good homogeneity, or weighting according to the position and distance of the next seat such as disgust A method of calculating may be used, or a method of performing weighting based on the number of people joining together, such as being disgusted alone, may be used. Moreover, you may calculate combining these suitably.
  • a usage schedule as service provision information.
  • character As an example, the definition of "character” according to the present embodiment will be described.
  • typing describes characters in several typical typologies
  • characterization theory describes characters as a combination of several characteristics.
  • the personality which is a broad character, may be classified into a natural temperament and an acquired character.
  • personality theory which is a characteristic theory of Robert Cloninger, is used.
  • three temperament parameters such as novelty search, reward dependency, and damage avoidance are the axes, and assuming a three-dimensional space as shown in FIG. 13, respective axes of novelty search, reward dependency, and damage avoidance Is normalized to 0 to 1 to define the following eight character types.
  • FIG. 14 is a flowchart showing the estimation process of the character type according to the present embodiment.
  • the affinity management server 2 selects a combination of fellow passengers (step S303), and calculates parameters in the selected combination from the sensor data (Step S306).
  • Parameters calculated from sensor data are calculated from, for example, a smile time, a smile co-occurrence time, a closed eye time, etc. calculated from a captured image taken while riding with a camera, or voice data collected while riding with a microphone It is assumed that the calculated speech time, the speech time ratio, etc., and the pulse average value or the pulse change value etc. based on the pulse value detected by the pulse sensor. Details will be described later.
  • the affinity management server 2 calculates a personality type parameter based on the above parameters (step S309).
  • the character type parameter is a parameter for determining the character type, and here, as an example, “reward dependent” and “damage avoidance” are calculated. Details will be described later.
  • step S312 the processing shown in the above steps S303 to S309 is performed on all the combinations of the passengers (step S312).
  • various parameters such as smile time
  • various parameters such as smile time
  • various parameters while the user 2 is riding with the user U3 are also calculated from the sensor data, and the personality type parameters are calculated.
  • various parameters (such as smile time) while the user 1 is in the vehicle with the user U2 are calculated from sensor data, and a character type parameter is calculated.
  • various parameters (smiling time etc.) while the user 1 is riding with the user U3 are also calculated from the sensor data to calculate a personality type parameter.
  • various parameters (such as smile time) while the user 3 is in the vehicle with the user U1 are calculated from sensor data, and a character type parameter is calculated.
  • various parameters (such as smile time) while the user 3 is in the vehicle with the user U1 are also calculated from the sensor data to calculate a personality type parameter.
  • the affinity management server 2 selects one passenger (step S315), estimates the character type in the passenger based on the calculated character type parameter (step S318), and stores the character type in the user information DB 221.
  • the character type of each user being corrected is corrected (updated) (step S321).
  • the affinity management server 2 repeats the processing of the above-mentioned steps S315 to S321 until all the passengers are selected and the character type is estimated and corrected (step S324).
  • step S306 Calculation of Parameters from Sensor Data Subsequently, the parameter calculation shown in step S306 will be described in detail.
  • the parameters are calculated as follows.
  • “Utterance time ratio” is a ratio of the speech of the user U1 and the user U2
  • “heart rate” is an average heart rate of the user U1.
  • “smile time change” and “heart rate change” are the increase and decrease in the first half and the second half of the ride time.
  • Each parameter is normalized to 0 to 1
  • the parameter of time is normalized by the unit time
  • physiological data such as heart rate is normalized by the minimum value and the maximum value of each person.
  • a time T during which the user U1 and the passenger (user U2) are on the same ride is obtained as shown in FIG. That is, for example, when the user U2 gets on first and the user U1 joins together and the user U2 gets off first, it becomes time T when the user U1 and the user U2 were on the same ride as shown in FIG.
  • the graph of the time change of the degree of smile of the user U1 at this time is shown in FIG.
  • the smile degree in the first half of the passenger time T (0 ⁇ t ⁇ T / 2) the time smile degree exceeds a smile threshold S th TS FH, the second half (T / 2 ⁇ t ⁇ T )
  • smile time variation (.DELTA.TS) is obtained by the following equation 1, for example.
  • the first half when the first half is continuously smiling but the second half is not smiling at all, the first half is not smiling at all and the second half is 0 when continuously smiling. That is, when the first half was laughing continuously but the second half was not laughing at all, it is considered that the first half was forced to laugh so as not to damage the relationship with people, so the smile was reduced in the second half, Is rated positively in "damage avoidance", which represents the suppression of
  • the graph of the time change of a heart rate of the user U1 is shown in FIG. As shown in FIG. 17, assuming that the average heart rate during the same time (0 ⁇ t ⁇ T) is HR avr and the resting heart rate is HR 0 , the normalized heart rate HR can be obtained by, for example, the following equation 2.
  • the character type (character type) is determined from the following conditions.
  • Personality type 00 if 0 ⁇ RD ⁇ 0.5 and 0 ⁇ HA ⁇ 0.5
  • Personality type 01 if 0 ⁇ RD ⁇ 0.5 and 0.5 ⁇ HA ⁇ 1.0
  • Personality type 10 if 0.5 ⁇ RD ⁇ 1.0 and 0 ⁇ HA ⁇ 0.5
  • Personality type 11 if 0.5 ⁇ RD ⁇ 1.0 and 0.5 ⁇ HA ⁇ 1.0
  • RD U2 0.5TS U1U2 + 0.5TCS U1U2 + (- 0.5) TCE U1U2 + 0.5TU U1U2 It becomes.
  • the reward dependency represents “relationship with people” such as whether it is social or not, it is evaluated positively based on, for example, smile time, smile co-occurrence time, and speech time, and a person like closed eye time. Be negatively assessed by the act of blocking the relationship with
  • HA U2 0.5 ⁇ TS U1 U2 + 0.5 HR U1 U2 It becomes.
  • smile time is reduced or heart rate is increased due to change in smile time or heart rate, for example.
  • smile time change if smile time is shorter in the second half than in the first half of the ride time, it is considered that the first half is forced to laugh so as not to lose relationships with people, and smiles decrease in the second half It is evaluated positively.
  • heart rate is higher than normal, it is considered to be apprehensive by getting on with other people, so it is correctly evaluated.
  • the personality type is estimated based on information (sensor data) at the time of using the service in the past, but the personality type of the user can not be estimated, such as the initial stage when the user starts using the service. Since there are also, it is possible to have the user input a questionnaire or the like that can estimate the character type when joining the service.
  • the questionnaire consists of the following questions
  • the affinity management server 2 can estimate the user's character type based on the answers of the following questions.
  • the question (1) above refers to the pursuit of novelty
  • the question (2) relates to the damage avoidance
  • the question (3) relates to the compensation dependency
  • the questions on the novelty search the damage avoidance and the compensation dependency “Yes / No”
  • "0/1" of each axis is determined, and the character type is determined.
  • the calculation of the degree of compatibility may be calculated based on sensor data obtained by sensing the user during service use, for example.
  • FIG. 18 is a flowchart showing the process of calculating the degree of compatibility according to the present embodiment. As shown in FIG. 18, first, when acquiring the sensor data of each user who is using the service, the affinity management server 2 selects the combination of the fellow passengers (step S333), and calculates the parameter in the selected combination from the sensor data (Step S336).
  • the parameters calculated from the sensor data are, for example, a smile time, a smile co-occurrence time, a closed eye time, etc. calculated from a captured image taken while being taken by a camera, similarly to the parameters used in the personality type estimation described above
  • a speech time, a speech time ratio, etc. calculated from voice data collected while taking a ride by a microphone, and a pulse average value, a pulse change value, etc. based on a pulse value detected by a pulse sensor are assumed.
  • the affinity management server 2 calculates the affinity degree in the combination selected based on the parameters (step S339), and corrects (updates) the affinity degree of each user stored in the affinity information DB 222 (step S342) .
  • the affinity management server 2 corrects the affinity between users, the affinity information between corresponding character types may also be corrected (updated). Details of affinity calculation will be described later.
  • the affinity management server 2 repeats the process of steps S333 to S342 for all combinations of passengers (step S345).
  • step S339 calculation of degree of compatibility shown in step S339 will be described using a specific example.
  • the degree of compatibility from x to y can be calculated, for example, by the following equation 4.
  • Compatibility factor U1U2 0.3 TS U1 U2 + 0.6 TCS U1 U2 + ( -0.8 ) TCE U1 U2 + 0.3 TU U1 U2 + 0.6 RU U1 U2 It becomes.
  • the degree of affinity is positively evaluated by smile time, smile co-occurrence time, speech time, and speech time ratio, and negatively evaluated by closed eye time.
  • the utterance time ratio of the user U1 and the user U2 may be expressed by the following equation 5, and may be set to 1 when both are equally balanced.
  • the user U1 when the user U1 is on the same floor as the user U2, the user U1 smiles a lot, becomes a smile together, and does not pretend to sleep, and he often talks as much as the user 2. Sometimes the affinity goes up.
  • the parameters (smile time, smile co-occurrence time, speech time, speech time ratio, closing time, etc.) used in the present embodiment are continuously measured while riding.
  • the parameters used in the present embodiment are not limited to those measured continuously while riding, but may be tied to a specific event while riding. For example, whether you enjoy rapid acceleration or deceleration while riding, such as "quick acceleration deceleration smile time", or negative emotions when you get caught in the traffic jam while riding like "smile time in traffic jam” It is also possible to introduce parameters such as whether it is fun or not.
  • parameters linked to a specific event while riding such as “quick acceleration / deceleration smile time” and “congestion smile time” can also be used in character type estimation. In this case, it is also possible to use "quick acceleration / deceleration smile co-occurrence time” or "jumping smile co-occurrence time”.
  • affinity information is used for affinity matching of the same share service, but the present embodiment is not limited to this, and compatibility information when using a certain sharing service is It is also possible to use for affinity matching in sharing service.
  • compatibility information acquired from a room sharing service user can be applied to a movie theater seat recommendation service.
  • the affinity management server 2 acquires sensor data of the user using the service from the service providing server 3B providing the room sharing service to generate and accumulate affinity information, and provides a seat recommendation service of a movie theater It is possible to perform affinity matching based on the stored affinity information in response to a request from 3C (seat reservation management server).
  • the service providing server 3B can perform affinity matching in the room sharing service. For example, calculation of compatibility and compatibility matching can be realized in the same manner by replacing “car passengers” in the ride share service of the first embodiment described above with “communers”.
  • the service information includes information on each room and information on requests from each user.
  • the information on the room includes service ID, name, location, charge, status (full / empty), and availability information.
  • service ID As shown in Table 7 above, the information on the room includes service ID, name, location, charge, status (full / empty), and availability information.
  • space information a user ID living in each room is shown.
  • the request information includes the request ID, the requested user ID, and the requested content information.
  • the content information indicates the area and fee desired by the user.
  • the data configuration of the user information and compatibility information is the same as that of the first embodiment.
  • service information stored in the service providing server 3C for providing a seat recommendation service of a movie theater is shown in the following Table 9 and Table 10.
  • the service information includes information on each movie theater and information on requests from each user.
  • the information on the movie theater includes the service ID, the name, the location, the charge, the status (full / empty), and the space information.
  • the space information indicates the user ID reserved for each seat.
  • the request information includes the request ID, the requested user ID, and the requested content information.
  • the content information indicates the area desired by the user, the screening title, and the screening time.
  • the data configuration of the user information and compatibility information is the same as that of the first embodiment.
  • the service providing server 3B has a location in the desired area based on the user ID of the request, the desired area, and the charge as normal matching processing, and List the rooms with vacancies.
  • a screen has been presented for presenting the user with "name, location, fee, number of people living together".
  • compatibility matching it is also possible to present a "degree of compatibility" indicating compatibility.
  • the affinity management server 2 can estimate the character type and calculate the degree of affinity based on the sensing data of the user who is using the service, as in the first embodiment.
  • the sensing data in the living room may be sensed only in the shared space when privacy is taken into consideration.
  • smile time, smile co-occurrence time, eye closing time, speech time, speech time ratio, pulse value, pulse change value, etc. are assumed.
  • the service providing server 3C for providing a seat recommendation service for a movie theater performs a normal matching process when there is a movie watching request from the user. That is, the service providing server 3C lists, based on the user ID of the request, the desired area, the title, and the time, movie theaters that have a location and a vacant seat in the desired area.
  • FIG. 19 shows an example of a seat recommendation screen according to the conventional matching.
  • the conventional seat recommendation screen 52 only displays whether the seat is vacant or not, and compatibility with surrounding users is not considered.
  • FIG. 20 shows an example of a seat recommendation screen based on affinity matching according to the present embodiment.
  • the degree of compatibility with the users in the surrounding seats is calculated for each vacant seat, and the vacant seats having a degree of compatibility of a predetermined value or more are indicated by thick lines. It is clearly stated as “vacant seat”.
  • the seat of a person who seems to be compatible or the "seat of a person who is likely to be incompatible” may be specified based on the degree of affinity.
  • FIG. 21 is a diagram for explaining calculation of the degree of compatibility of vacant seats according to the present embodiment. As shown in FIG. 21, there are seats [S1, S2, S3, S4, S5, S6, S7, S8] around a vacant seat, seats [S3, S6, S7] are vacant, and the other seats are vacant. It is assumed that there is a reserved user.
  • the affinity management server 2 selects a user from the list of reserved users [U31, U32, U34, U35, U38] and obtains the compatibility degree. If the compatibility information of the requested user and the reserved user exists in the interpersonal compatibility information, the compatibility degree is acquired from the interpersonal compatibility information, and if not, the personality type of the requested user that can be acquired from the user information The affinity degree is acquired from the personality type inter-compatibility information by using the personality type of the reserved user.
  • the degree of affinity of the vacant seat is obtained, for example, as an average of the degrees of affinity of the surrounding seats described above. Alternatively, if there is a single person who is close to the predetermined value (lower limit), the vacant seat or the screening may not be recommended.
  • a present Example is not limited to this, It is possible to utilize compatibility information between other various sharing services. For example, it is also possible to use a service that provides comfortable accommodation with a well-being with a person who is compatible with a homestay, or a service that provides a comfortable trip taking into consideration compatibility with a person in the air or train.
  • the functions of the user terminal 1, the affinity management server 2, or the service providing server 3 in hardware such as the CPU, ROM, and RAM built in the user terminal 1, the affinity management server 2, or the service providing server 3 described above. It is also possible to create a computer program for exerting A computer readable storage medium storing the computer program is also provided.
  • a storage unit that stores compatibility information indicating compatibility between a plurality of users generated based on sensor data obtained by sensing a plurality of users in service use;
  • a communication unit that receives a service request from a user;
  • a control unit configured to control, via the communication unit, service provision information according to the service request based on compatibility information between the user and another user already stored in the storage unit;
  • a service information providing system comprising: (2) The control unit Based on compatibility information between the user and other users already stored in the storage unit, The service providing information related to the service according to the service request includes compatibility information with other users who enjoy the service, and controls to be provided to the user via the communication unit.
  • the service information providing system according to (1).
  • (3) The control unit When compatibility information between the user and another user who enjoys the service is not stored in the storage unit, compatibility with the other user who enjoys the service according to the information on the user
  • the service information providing system according to (2) which estimates information.
  • the service information providing system provides service information on ride sharing services,
  • the storage unit stores compatibility information indicating compatibility between a plurality of users generated based on sensor data obtained when the user uses the ride sharing service with another user,
  • the control unit When the communication unit receives a service request for receiving the same ride sharing service from the user, it is estimated that the compatibility is relatively incompatible from the compatibility information associated with the user stored in the storage unit.
  • the control unit When it is necessary to provide a service that shares the same car in the same time zone as other users who are estimated to be relatively incompatible with the user in order to respond to the service request, another user also rides The service information providing system according to the above (5), which provides a usage schedule to be received as service providing information. (7) The control unit The service information providing system according to (5), which provides, as service provision information, a usage schedule that prevents the user and the other users from being next to each other.
  • the control unit Service provision according to the service request based on compatibility information between the user and other users when using a service different from the service for which the service request is stored, which is already stored in the storage unit
  • the service information providing system according to any one of (1) to (7), which controls information to be provided via the communication unit.
  • a service information providing system for providing compatibility information between a plurality of users who use the service to a service information providing server operated by a service provider who provides a service to a plurality of users sharing the same space in the same time zone ,
  • a storage unit that stores compatibility information indicating compatibility between a plurality of users generated based on sensor data obtained by sensing a plurality of users in service use;
  • a communication unit that receives, via the service information providing server, information identifying the user corresponding to the service request from the user and other users enjoying the service with the user; Based on the compatibility information between the user and another user already stored in the storage unit, the compatibility information between the user and another user who enjoys the service via the communication unit
  • a control unit that performs control to provide the service information providing server;
  • a service information providing system comprising: (10) The control unit Based on compatibility information between the user and another user when a service related to another service information providing server, which is already stored in the storage unit, is used in the past, the user and the service can be enjoyed
  • Processor is Storing compatibility information indicating compatibility between a plurality of users generated based on sensor data obtained by sensing a plurality of users in use of the service in the storage unit; Receiving a service request from a user by the communication unit; Controlling to provide service provision information according to the service request via the communication unit, based on compatibility information between the user and another user already stored in the storage unit; Control methods, including: (12) A service information providing system for providing compatibility information between a plurality of users who use the service to a service information provision server operated by a service provider who provides services to a plurality of users sharing the same space in the same time zone In the control method, Processor is Storing compatibility information indicating compatibility between a plurality of users generated based on sensor data obtained by sensing a plurality of users in use of the service in the storage unit; Receiving by the communication unit via

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Development Economics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【課題】利用者や共有サービス提供者に負担を掛けることなく取得した共有サービス利用者の相性情報に基づいて、様々なサービスリクエストに応えることが可能なサービス情報提供システムおよび制御方法を提供する。 【解決手段】同じ時間帯に同じ空間をシェアしている複数ユーザに対してサービスを提供するサービス業者が運営するサービス情報提供システムにおいて、サービス利用中の複数ユーザをセンシングすることにより得られたセンサデータに基づき生成される複数ユーザ間の相性を示す相性情報を記憶する記憶部と、ユーザからのサービスリクエストを受信する通信部と、前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、前記サービスリクエストに応じたサービス提供情報を、前記通信部を介して提供するように制御する制御部と、を備える、サービス情報提供システム。

Description

サービス情報提供システムおよび制御方法
　本開示は、サービス情報提供システムおよび制御方法に関する。
　従来、複数の人が同じ時間と空間を共有するサービスでは、サービスの内容だけでなく、共有相手との相性によって、そのサービスが楽しかったり不快だったりすることがあった。
　共有サービスを提供する技術に関し、例えば下記特許文献１には、ユーザと相性の良い顧客を検索可能な相乗り車検索システムが開示されている。かかる車検索システムでは、属性が近い人を相乗り者として推薦している。具体的には、性別、年齢、趣味、家族構成が一致しているか否か、購買行動（来店の時間帯や購買品目）が同じか否か、また、地理条件（目的地へのルート）が近いか否かに基づいてマッチングを行っている。
　また、下記特許文献２では、複数の利用者間の関係を表す利用者関係情報に基づいて、参加するコミュニティを決定するサービスが開示されている。利用者関係情報には、複数の利用者間の互いに対する主観的な評価（相手の性格、自分との相性、相手の情報の正確さ等についての評価）が含まれている。特許文献２に記載のシステムでは、利用者関係情報に基づいて各コミュニティの点数が算出され、利用者に合った参加コミュニティが推薦される。
　また、下記特許文献３では、帰宅時に乗合希望患者にタクシーを配車する乗合タクシーシステムが開示されている。かかるシステムでは、院内処理完了時刻が同じ時間帯に属し且つ居住地が同じ地域に属する乗合希望患者を乗車定員毎に区切り、同じタクシーの乗合患者群に設定している。この際、特別な設備を持つ車種の希望や喫煙可否を考慮して乗合患者群を設定したり、空気感染性の疾病（例えばインフルエンザ）である場合には乗合患者群から除外したりすることが可能である。
特開２０１５－７６０２８号公報 特開２００４－１５１９６６号公報 特開２００３－２１６７２７号公報
　しかしながら、従来のシステムでは、サービス利用時に多くのユーザ情報が必要であり、ユーザ側の負荷が高かった。また、多くのユーザの組み合わせの相性を考慮する必要があったため、サービス提供者側の負荷も高くなっていた。
　そこで、本開示では、利用者や共有サービス提供者に負担を掛けることなく取得した共有サービス利用者の相性情報に基づいて、様々なサービスリクエストに応えることが可能なサービス情報提供システムおよび制御方法を提案する。
　本開示によれば、同じ時間帯に同じ空間をシェアしている複数ユーザに対してサービスを提供するサービス業者が運営するサービス情報提供システムにおいて、サービス利用中の複数ユーザをセンシングすることにより得られたセンサデータに基づき生成される複数ユーザ間の相性を示す相性情報を記憶する記憶部と、ユーザからのサービスリクエストを受信する通信部と、前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、前記サービスリクエストに応じたサービス提供情報を、前記通信部を介して提供するように制御する制御部と、を備える、サービス情報提供システムを提案する。
　本開示によれば、同じ時間帯に同じ空間をシェアしている複数ユーザに対してサービスを提供するサービス業者が運営するサービス情報提供サーバに、当該サービスを利用する複数ユーザ間の相性情報を提供するサービス情報提供システムにおいて、サービス利用中の複数ユーザをセンシングすることにより得られたセンサデータに基づき生成される複数ユーザ間の相性を示す相性情報を記憶する記憶部と、前記サービス情報提供サーバを介して、ユーザからのサービスリクエストに対応する当該ユーザと、当該ユーザと供に同サービスを享受する他のユーザを識別する情報を受信する通信部と、前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、前記ユーザと、当該サービスを供に享受する他のユーザとの相性情報を、前記通信部を介して前記サービス情報提供サーバに提供するように制御する制御部と、を備える、サービス情報提供システムを提案する。
　本開示によれば、同じ時間帯に同じ空間をシェアしている複数ユーザに対してサービスを提供するサービス業者が運営するサービス情報提供システムの制御方法において、プロセッサが、ユーザからのサービスリクエストを通信部により受信することと、サービス利用中の複数ユーザをセンシングすることにより得られたセンサデータに基づき生成される複数ユーザ間の相性を示す相性情報を記憶する記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、前記サービスリクエストに応じたサービス提供情報を、前記通信部を介して提供するように制御することと、を含む制御方法を提案する。
　本開示によれば、同じ時間帯に同じ空間をシェアしている複数ユーザに対してサービスを提供するサービス業者が運営するサービス情報提供サーバに、当該サービスを利用する複数ユーザ間の相性情報を提供するサービス情報提供システムの制御方法において、プロセッサが、サービス利用中の複数ユーザをセンシングすることにより得られたセンサデータに基づき生成される複数ユーザ間の相性を示す相性情報を記憶部に記憶することと、前記サービス情報提供サーバを介して、ユーザからのサービスリクエストに対応する当該ユーザと、当該ユーザと供に同サービスを享受する他のユーザを識別する情報を通信部により受信することと、前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、前記ユーザと、当該サービスを供に享受する他のユーザとの相性情報を、前記通信部を介して前記サービス情報提供サーバに提供するように制御することと、を含む、制御方法を提案する。
　以上説明したように本開示によれば、利用者や共有サービス提供者に負担を掛けることなく取得した共有サービス利用者の相性情報に基づいて、様々なサービスリクエストに応えることが可能となる。
　なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。
本開示の一実施形態による情報処理システムの概要について説明する図である。 本実施形態による情報処理システムの全体構成の一例を示す図である。 本実施形態によるユーザ端末の構成の一例を示すブロック図である。 本実施形態による相性管理サーバの構成の一例を示すブロック図である。 本実施形態によるサービス提供サーバの構成の一例を示すブロック図である。 本実施形態による情報処理システムの動作処理を示すシーケンス図である。 本実施形態による相性管理サーバの動作処理を示すフローチャートである。 本実施形態による相性管理サーバの動作処理を示すフローチャートである。 本実施形態の第１の実施例による相性情報を考慮したマッチング処理を示すフローチャートである。 本実施形態の第１の実施例による通常のマッチングによりリストアップしたルートの一例を示す図である。 従来のライドシェアサービスにおけるルート選択画面の一例を示す図である。 本実施形態の第１の実施例による相性情報を考慮したライドシェアサービスにおけるルート選択画面の一例を示す図である。 本実施形態の第１の実施例による性格類型の一例について説明する図である。 本実施形態の第１の実施例による性格類型の推定処理を示すフローチャートである。 本実施形態の第１の実施例による同乗時間について説明する図である。 本実施形態の第１の実施例によるユーザＵ１の笑顔度の時間変化のグラフの一例を示す図である。 本実施形態の第１の実施例によるユーザＵ１の心拍数の時間変化のグラフの一例を示す図である。 本実施形態の第１の実施例による相性度の算出処理を示すフローチャートである。 従来の座席推薦画面の一例を示す図である。 本実施形態の第２の実施例による座席推薦画面の一例を示す図である。 本実施形態の第２の実施例による空席の相性度の算出について説明する図である。
　以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
　また、説明は以下の順序で行うものとする。
　１．本開示の一実施形態による情報処理システムの概要
　２．構成
　　２－１．ユーザ端末の構成
　　２－２．相性管理サーバの構成
　　２－３．サービス提供サーバの構成
　３．動作処理
　４．各実施例
　　４－１．第１の実施例
　　（４－１－１．マッチング処理）
　　（４－１－２．性格類型の推定処理）
　　（４－１－３．相性度の算出処理）
　　４－２．第２の実施例
　５．まとめ
　＜＜１．本開示の一実施形態による情報処理システムの概要＞＞
　図１は、本開示の一実施形態による情報処理システムの概要について説明する図である。図１に示すように、本実施形態による情報処理システム（サービス情報提供システム）では、例えば過去にシェアハウス等のシェアリングサービスを利用したときのユーザ間の相性情報に基づいて、次にユーザが同じまたは異なるシェアリングサービス（例えばライドシェア）を利用する際に相性のよい相手をマッチングすることが可能である。シェアリングサービスとは、複数ユーザが同じ時間帯に同じ空間を共有して利用するサービスであって、近年は、例えば複数のユーザが家を共有するシェアハウスや乗車を共有するライドシェアが普及している。また、電車、バス、映画館、劇場といった多数の人物（見ず知らずの人達）と時間と空間を共有する場合も、本明細書でのシェアリングサービスに含む。また、ここでいう「空間」とは、現実世界のみならず、仮想世界（ＶＲ：Ｖｉｒｔｕａｌ　Ｒｅａｌｉｔｙ）も含む。
　本情報処理システムでは、より具体的には、一度目のサービス利用時にサービス利用中のユーザをセンシングして得たセンシングデータに基づいて相性情報を生成し、二度目のサービス利用時に、生成した相性情報を利用して相性のよい共有相手をマッチングすることが可能である。
　このように、本情報処理システムでは、センシングデータを解析することによってユーザ間の相性を推定するため、サービスの申込時に多くのユーザ情報を入力する必要がなく、利用者に負担を掛けることがない。
　また、相性情報の生成については下記に詳述するが、例えば一度目のサービス利用時にサービス利用中のユーザをセンシングして得たセンシングデータに基づいて各ユーザの性格等を類型化し、類型化した性格タイプ間での相性を相性情報として生成する。次いで、二度目のサービス利用時に、生成した相性情報に基づいて、利用者の性格タイプと相性の良い性格タイプの人物を共有相手として推薦するようにしてもよい。
　類型化した性格タイプに基づいて相性マッチングを行うことで、過去に一緒になったことのないユーザ間の相性も推定することも可能となり、様々なシェアリングサービスにおけるサービスリクエストに応えることができる。
　また、本情報処理システムは、性格タイプ（性格類型とも称す）に基づいて相性マッチングを行うことができるため、多くのユーザの組み合わせを考慮する必要がなく、共有サービス提供者に負担を掛けることがない。
　続いて、このような本実施形態による情報処理システムの全体構成について図２を参照して説明する。図２は、本実施形態による情報処理システムの全体構成の一例を示す図である。
　図２に示すように、本実施形態による情報処理システムは、ユーザ端末１と、相性管理サーバ２と、サービス提供サーバ３を含む。
　ユーザ端末１は、各ユーザが利用する情報通信端末であって、例えばスマートフォン、携帯電話、タブレット端末、ＰＣ（パーソナルコンピュータ）、ウェアラブル装置（スマートアイグラス、スマートバンド、スマートウォッチ、スマートネックスピーカ等）、音楽再生装置、またはゲーム装置等が想定される。
　ユーザは、ユーザ端末１からサービス提供サーバ３に接続し、サービスリクエストを送信したり、サービスの提供若しくはサービスの提供を享受するための情報を受信したりする。
　相性管理サーバ２は、サービス利用時の各ユーザのセンシングデータを解析して相性情報を生成、管理し、サービス提供サーバ３からの要求に応じて相性情報を提供する。
　サービス提供サーバ３は、ユーザ端末１からのサービスリクエストに応じてシェアリングサービスの提供やシェアリングサービス提供のための情報の提示をユーザに行う。サービス提供サーバ３は、各シェアリングサービスに対応するものであって、例えばサービス提供サーバ３Ａはライドシェアサービスの提供サーバ、サービス提供サーバ３Ｂはシェアハウスサービスの提供サーバ、サービス提供サーバ３Ｃは映画予約サービスの提供サーバであってもよい。
　また、本実施形態によるサービス提供サーバ３は、シェアリングサービスの提供を行う際、相性管理サーバ２から取得した相性情報を考慮し、相性の良い相手をユーザに推薦したり、相手の相性度をユーザに提示したりすることが可能である。
　また、本実施形態によるサービス提供サーバ３は、サービス利用時のユーザをセンサ群４によりセンシングし、センシングデータ若しくはセンシングデータを解析した解析結果を相性管理サーバ２に送信する。センサ群４は、例えばシェアする空間に設けられていてもよいし、ユーザ端末１をセンサ群４として利用してもよい。
　以上、本開示の一実施形態による情報処理システムについて説明した。続いて、本実施形態による情報処理システムに含まれる各装置の具体的な構成について図面を参照して説明する。
　＜＜２．構成＞＞
　　＜２－１．ユーザ端末１の構成＞
　図３は、本実施形態によるユーザ端末１の構成の一例を示すブロック図である。図３に示すように、ユーザ端末１は、制御部１０、通信部１１、入力部１２、出力部１３、および記憶部１４を有する。
　制御部１０は、演算処理装置および制御装置として機能し、各種プログラムに従ってユーザ端末１内の動作全般を制御する。制御部１０は、例えばＣＰＵ（Central　Processing　Unit）、マイクロプロセッサ等の電子回路によって実現される。また、制御部１０は、使用するプログラムや演算パラメータ等を記憶するＲＯＭ（Read　Only　Memory）、及び適宜変化するパラメータ等を一時記憶するＲＡＭ（Random　Access　Memory）を含んでいてもよい。
　また、本実施形態による制御部１０は、ユーザによる操作入力に従って、所定のシェアサービスの利用を要求するサービスリクエストを通信部１１からサービス提供サーバ３に送信するよう制御する。また、制御部１０は、サービス提供サーバ３から受信したサービス情報を出力部１３から出力してユーザに提示するよう制御する。
　（通信部１１）
　通信部１１は、有線または無線により外部装置と接続し、外部装置とデータの送受信を行う。例えば通信部１１は、ネットワークを介してサービス提供サーバ３と接続し、データの送受信を行う。また、通信部１１は、例えば有線／無線ＬＡＮ（Local　Area　Network）、またはＷｉ－Ｆｉ（登録商標）、携帯通信網（ＬＴＥ（Long　Term　Evolution）、３Ｇ（第３世代の移動体通信方式））等によりネットワーク３と通信接続する。
　（入力部１２）
　入力部１２は、ユーザ端末１への入力情報を検出し、制御部１０に入力情報を出力する機能を有する。例えば入力部１２は、操作入力部や音声入力部により実現され得る。操作入力部は、ユーザによる操作指示を受付け、その操作内容を制御部１０に出力する。操作入力部は、タッチセンサ、圧力センサ、若しくは近接センサであってもよい。あるいは、操作入力部は、ボタン、スイッチ、およびレバーなど、物理的構成であってもよい。
　また、音声入力部は、マイクロホンと、そのマイクロホンで得られた音声信号を増幅処理するマイクアンプ部と、音声信号にデジタル変換するＡ／Ｄ変換器により実現され、音声信号を制御部１０に出力する。
　（出力部１３）
　出力部１３は、制御部１０から出力された情報をユーザに提示する機能を有する。例えば出力部１３は、表示部、投影部、音声出力部、振動部等により実現される。表示部は、サービスリクエストの入力を行う画面等を出力する表示装置である。この表示部は、例えば、液晶ディスプレイ（ＬＣＤ：Liquid　Crystal　Display）、有機ＥＬ（Electro　Luminescence）ディスプレイなどの表示装置であってもよい。
　また、音声出力部は、音声信号を再生するスピーカと、スピーカに対するアンプ回路を有する。
　（記憶部１４）
　記憶部１４は、制御部１０の処理に用いられるプログラムや演算パラメータ等を記憶するＲＯＭ（Read　Only　Memory）、および適宜変化するパラメータ等を一時記憶するＲＡＭ（Random　Access　Memory）により実現される。
　以上、本実施形態によるユーザ端末１の構成について具体的に説明した。なおユーザ端末１の構成は、図３に示す例に限定されず、例えばサービス利用時のユーザの状況を検知するセンサ（加速度センサ、ジャイロセンサ、地磁気センサ、位置測位部、生体センサ、環境センサ等）をさらに有していてもよい。この場合、ユーザ端末１は、センサにより取得したセンサデータを、サービス提供サーバ３に送信する。
　　＜２－２．相性管理サーバ２の構成＞
　図４は、本実施形態による相性管理サーバ２の構成の一例を示すブロック図である。図４に示すように、相性管理サーバ２は、制御部２０、通信部２１、および記憶部２２を有する。
　（制御部２０）
　制御部２０は、演算処理装置および制御装置として機能し、各種プログラムに従って相性管理サーバ２内の動作全般を制御する。制御部２０は、例えばＣＰＵ（Central　Processing　Unit）、マイクロプロセッサ等の電子回路によって実現される。また、制御部２０は、使用するプログラムや演算パラメータ等を記憶するＲＯＭ（Read　Only　Memory）、及び適宜変化するパラメータ等を一時記憶するＲＡＭ（Random　Access　Memory）を含んでいてもよい。
　また、本実施形態による制御部２０は、相性推定部２０１およびマッチング部２０２としても機能する。
　相性推定部２０１は、サービス利用時にセンシングされた各ユーザのセンサデータに基づき、ユーザ間の相性を推定する。センサデータとしては、例えばカメラにより撮像された顔画像、マイクロホンにより収音された音声、生体センサにより検知された生体センサデータ（脈拍、心拍、発汗、呼吸等）等を用いてもよい。相性推定部２０１は、これらのセンサデータを解析し、ユーザの表情（笑顔の継続時間など）、発話時間（話が盛り上がっているかなど）、心拍数（安静状態であったかなど）に基づき、共有者との相性度を算出する。算出された相性度は、相性情報ＤＢ２２２に、相性ＩＤ、ユーザＩＤ（本人）、および相手ユーザＩＤと共に、蓄積される。
　また、相性推定部２０１は、性格類型毎の相性度を算出することも可能である。例えばアンケート若しくはセンサデータに基づいて各ユーザの性格類型を判断し、ユーザ間の相性情報に基づいて性格類型間の相性度を算出することも可能である。これにより、過去に共有したことのない他ユーザとの相性度を推定することも可能となる。
　マッチング部２０２は、サービス提供サーバ３からのリクエストに応じて、相性情報ＤＢ２２２に蓄積された相性情報に基づいて、特定のユーザと相性の良い共有者（シェアリングサービス）のマッチングを行う。なお本実施形態による制御部２０は、マッチング部２０２によるマッチング結果の他、特定のユーザと１以上の他のユーザとの相性情報をサービス提供サーバ３に返信するようにしてもよい。
　（通信部２１）
　通信部２１は、有線または無線により外部装置と接続し、外部装置とデータの送受信を行う。例えば通信部２１は、ネットワークを介してサービス提供サーバ３と接続し、データの送受信を行う。また、通信部２１は、例えば有線／無線ＬＡＮ（Local　Area　Network）、またはＷｉ－Ｆｉ（Wireless　Fidelity、登録商標）等により外部装置と通信接続する。
　（記憶部２２）
　記憶部２２は、制御部２０の処理に用いられるプログラムや演算パラメータ等を記憶するＲＯＭ、および適宜変化するパラメータ等を一時記憶するＲＡＭにより実現される。例えば本実施形態による記憶部２２は、ユーザ情報ＤＢ（データベース）２２１および相性情報ＤＢ２２２を記憶する。
　ユーザ情報ＤＢ２２１には、ユーザ情報が蓄積されている。ユーザ情報は、例えばユーザＩＤ、氏名、および相性情報（ここでは、相性情報を示す相性ＩＤ）を含む。
　相性情報ＤＢ２２２には、相性情報が蓄積されている。相性情報は、相性ＩＤに紐付けられ、ユーザＩＤ、相手ユーザＩＤ、および相性度を含む。なお本実施形態において、ユーザ個人間の相性情報には、一方のユーザからの相性度と、他方のユーザからの相性度が含まれる。例えば「ユーザＡとユーザＢ間の相性情報」として、「ユーザＡから見たユーザＢとの相性度」と、「ユーザＢから見たユーザＡとの相性度」がそれぞれ算出される。
　以上、本実施形態による相性管理サーバ２の構成について具体的に説明した。なお図４に示す相性管理サーバ２の構成は一例であって、本実施形態はこれに限定されない。例えば相性管理サーバ２の少なくとも一部の構成が外部装置にあってもよいし、制御部２０の各機能の少なくとも一部がユーザ端末１、通信距離が比較的ユーザ端末１に近い情報処理端末（例えば、いわゆるエッジサーバなど）、またはサービス提供サーバ３により実現されてもよい。このように、相性管理サーバ２の各構成を適宜分散することで、リアルタイム性の向上や処理負担の軽減、さらにはセキュリティを担保することが可能となる。
　例えば、相性管理サーバ２は、サービス提供サーバ３からのリクエストに応じて、特定ユーザの相性情報を返信し、サービス提供サーバ３において相性の良い共有者のマッチングが行われてもよい。
　　＜２－３．サービス提供サーバ３の構成＞
　図５は、本実施形態によるサービス提供サーバ３の構成の一例を示すブロック図である。図５に示すように、サービス提供サーバ３は、制御部３０、通信部３１、および記憶部３２を有する。
　（制御部３０）
　制御部３０は、演算処理装置および制御装置として機能し、各種プログラムに従ってサービス提供サーバ３内の動作全般を制御する。制御部３０は、例えばＣＰＵ（Central　Processing　Unit）、マイクロプロセッサ等の電子回路によって実現される。また、制御部３０は、使用するプログラムや演算パラメータ等を記憶するＲＯＭ（Read　Only　Memory）、及び適宜変化するパラメータ等を一時記憶するＲＡＭ（Random　Access　Memory）を含んでいてもよい。
　また、本実施形態による制御部３０は、サービス提供制御部３０１としても機能する。サービス提供制御部３０１は、シェアリングサービスの提供に関する各種動作処理を行う。例えば、ライドシェアリングサービスの場合は、ユーザからの要求に応じて、シェアできる車の日時や走行経路をユーザに提示する。また、シェアハウスサービスの場合は、シェアできる家の候補を提示する。また、本実施形態によるサービス提供制御部３０１は、シェアする車や家の候補をユーザに提示する際に、相性管理サーバ２から取得した相性情報に基づいて、ユーザと共有者との相性も提示することが可能である。これによりユーザは、例えば相性の良い同乗者と乗り合わせる車を選び、快適にライドシェアすることができる。また、サービス提供制御部３０１は、相性情報に基づいて比較的相性の良い組み合わせでシェアするよう自動的に共有者の振り分けを行い、ユーザが選択しなくとも快適なシェアができるようにしてもよい。
　また、本実施形態による制御部３０は、サービス利用中のユーザをセンサ群４（図２参照）によりセンシングしたセンサデータを、通信部３１を介してセンサ群４から受信し、ユーザＩＤと紐付けて相性管理サーバ２に送信する。センサ群４は、例えばシェアしている空間（車内、家の中など）に設けられ、より具体的には、カメラ、位置測位部、マイクロホン、生体センサ等が想定される。
　カメラは、撮像レンズ、絞り、ズームレンズ、およびフォーカスレンズ等により構成されるレンズ系、レンズ系に対してフォーカス動作やズーム動作を行わせる駆動系、レンズ系で得られる撮像光を光電変換して撮像信号を生成する固体撮像素子アレイ等を有する。固体撮像素子アレイは、例えばＣＣＤ（Ｃｈａｒｇｅ　Ｃｏｕｐｌｅｄ　Ｄｅｖｉｃｅ）センサアレイや、ＣＭＯＳ（Ｃｏｍｐｌｅｍｅｎｔａｒｙ　Ｍｅｔａｌ　Ｏｘｉｄｅ　Ｓｅｍｉｃｏｎｄｕｃｔｏｒ）センサアレイにより実現されてもよい。
　位置測位部は、外部からの取得信号に基づいてセンサ群４が設けられている場所（例えば自動車）の現在位置を検知する機能を有する。具体的には、例えば位置測位部は、ＧＰＳ（Global　Positioning　System）測位部により実現され、ＧＰＳ衛星からの電波を受信して、当該場所が存在している位置を検知する。また、位置測位部は、ＧＰＳの他、例えばＷｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、携帯電話・ＰＨＳ・スマートフォン等との送受信、または近距離通信等により位置を検知するものであってもよい。
　生体センサは、ユーザの生体情報を検知する検知部であって、例えば、体温センサ、静脈センサ、脈拍センサ、心拍センサ、発汗センサ、脳波センサ等により実現される。
　（通信部３１）
　通信部３１は、有線または無線により外部装置と接続し、外部装置とデータの送受信を行う。例えば通信部３１は、ネットワークを介して相性管理サーバ２と接続し、データの送受信を行う。また、通信部３１は、例えば有線／無線ＬＡＮ（Local　Area　Network）、またはＷｉ－Ｆｉ（Wireless　Fidelity、登録商標）等により外部装置と通信接続する。
　（記憶部３２）
　記憶部３２は、制御部３０の処理に用いられるプログラムや演算パラメータ等を記憶するＲＯＭ、および適宜変化するパラメータ等を一時記憶するＲＡＭにより実現される。例えば本実施形態による記憶部３２は、サービス情報ＤＢ３２１を記憶する。サービス情報には、シェアリングサービスの提供に用いる情報が含まれている。例えばライドシェアの場合、車に関する情報（車ＩＤ、状態（サービス中／空車）、現在地、目的地、到着予定時刻等）と、各ユーザからのリクエストに関する情報（リクエストＩＤ、ユーザＩＤ、リクエスト時刻、現在地、目的地等）が蓄積されている。
　以上、本実施形態によるサービス提供サーバ３の構成について具体的に説明した。なお図５に示すサービス提供サーバ３の構成は一例であって、本実施形態はこれに限定されない。例えばサービス提供サーバ３の少なくとも一部の構成が外部装置にあってもよいし、制御部３０の各機能の少なくとも一部がユーザ端末１または通信距離が比較的ユーザ端末１に近い情報処理端末（例えば、いわゆるエッジサーバなど）により実現されてもよい。このように、サービス提供サーバ３の各構成を適宜分散することで、リアルタイム性の向上や処理負担の軽減、さらにはセキュリティを担保することが可能となる。
　＜＜３．動作処理＞＞
　続いて、本実施形態による情報処理システムの動作処理について図６～図８を参照して説明する。本実施形態では、時間と空間を共有するシェアリングサービスにおいて、ユーザ間の相性を考慮して相性マッチングを行う。
　　（全体の流れ）
　図６は、本実施形態による情報処理システムの動作処理を示すシーケンス図である。図６に示すように、まず、ユーザ端末１は、利用したいシェアサービスを提供しているサービス提供サーバ３に、サービスリクエストを行う（ステップＳ１）。
　次に、サービス提供サーバ３は、ユーザからのリクエストに応じて、当該ユーザと、当該ユーザによりリクエストされたシェアサービスの共有者候補となる他ユーザのＩＤを少なくとも含む相性リクエストを、相性管理サーバ２に送信する（ステップＳ２）。
　次いで、相性管理サーバ２は、リクエストされたユーザ間の相性マッチングを行い（ステップＳ３）、マッチング結果として相性情報をサービス提供サーバ３に返信する（ステップＳ４）。
　次に、サービス提供サーバ３は、マッチング結果に基づくサービス提供情報をユーザ端末１に送信する（ステップＳ５）。サービス提供情報には、少なくとも共有者との相性情報が含まれている。例えば、ライドシェアサービスを提供するサービス提供サーバ３の場合、比較的相性が合わないと推定される他のユーザと同じ時間帯に同じ車をシェアすることがないような利用スケジュールをサービス提供情報として生成し、ユーザ端末１に送信する。
　次いで、ユーザ端末１は、受信したサービス提供情報を表示してユーザに提示し（ステップＳ６）、提示したサービスがユーザにより選択された場合（ステップＳ７）、サービス提供を開始する（ステップＳ８、Ｓ９）。例えばライドシェアサービスの場合、ユーザに乗車時刻および乗車地点を通知すると共に、所定の自動車に利用者に関する情報を通知したりする。
　さらに、本実施例では、サービス利用中のユーザをセンサ群４によりセンシングしたセンサデータを取得し（ステップＳ１０）、当該センサデータを相性管理サーバ２に送信する（ステップＳ１１）。
　そして、相性管理サーバ２は、受信したセンサデータに基づいてユーザ間の相性度を算出し、ユーザＩＤ等と紐付けて相性情報として蓄積する（ステップＳ１２）。この際、相性管理サーバ２は、各ユーザの性格類型を推定し、性格類型間の相性度として、性格類型に紐付けた相性情報を蓄積してもよい。蓄積した相性情報は、次回の相性マッチングの際に利用され得る。
　このように、本実施例では、サービスリクエストに応じて、過去のシェアサービス利用中にセンシングされたセンサデータを解析して得られた相性情報を用いて、共有者候補との相性マッチングを行い、より快適なシェアサービスを提供することが可能となる。
　また、過去に一緒になったことのないユーザ間であっても、性格類型に基づいて相性マッチングを行うことが可能である。
　　（相性管理サーバ２の動作処理）
　次いで、本実施形態による相性管理サーバ２の動作処理について具体的に説明する。図７および図８は、相性管理サーバ２の動作処理を示すフローチャートである。
　図７に示すように、相性管理サーバ２は、サービス提供サーバ３から相性リクエストがあった場合（ステップＳ１０３／Ｙｅｓ）、蓄積された相性情報に基づいて、相性リクエストで指定されたユーザ間の相性マッチングを行う（ステップＳ１０６）。
　次いで、相性管理サーバ２は、相性マッチングの結果をサービス提供サーバ３に返信する（ステップＳ１０９）。
　また、図８に示すように、サービス提供サーバ３から、サービス利用中のユーザをセンシングしたセンサデータを受信した場合（ステップＳ１１２／Ｙｅｓ）、相性管理サーバ２の相性推定部２０１は、各ユーザ個人間の相性度を算出する（ステップＳ１１５）。
　次いで、相性推定部２０１は、各ユーザの性格類型を推定し（ステップＳ１１８）、上記個人間の相性度を参照して性格類型間の相性度を算出する（ステップＳ１２１）。そして、相性推定部２０１は、算出した各相性度を相性情報として相性情報ＤＢ２２２に蓄積する（ステップＳ１２４）。具体的には、相性推定部２０１は、個人間の相性度をユーザＩＤに紐付けて蓄積し、性格類型間の相性度を性格類型に紐付けて蓄積する。
　本実施形態による相性管理サーバ２は、図７に示す相性マッチング処理および図８に示す相性度算出処理をそれぞれ繰り返し、相性度の蓄積および蓄積した相性度を用いた相性マッチングを行い得る。
　＜＜４．各実施例＞＞
　続いて、本実施形態による情報処理システムについて複数の実施例を用いて具体的に説明する。
　　＜４－１．第１の実施例＞
　第１の実施例では、ライドシェアリングサービスにおいて、相性マッチングに基づくサービスの提供（ルート検索等）について説明する。本実施例では、例えば比較的相性が合わないと推定される他のユーザと同じ時間帯に同じ車をシェアすることがないような利用スケジュールをサービス提供情報としてユーザに提供することが可能となる。
　本実施例による基本的な構成および動作処理は図２～図８に示す通りであるため、ここでは本実施例の特徴的な構成および動作処理について説明する。
　（４－１－１．マッチング処理）
　図９は、本実施例による相性情報を考慮したマッチング処理を示すフローチャートである。
　図９に示すように、まず、サービス提供サーバ３は、ユーザからライドシェアのリクエストがあった場合、リクエストに応じて、通常のマッチング処理を行う（ステップＳ２０３）。リクエストには、「ユーザＩＤ、時刻、ユーザの現在地、および目的地」が含まれ、サービス提供サーバ３は、サービス情報ＤＢ３２１に蓄積されているサービス情報と、他ユーザからのリクエスト情報を参照し、シェアリング可能な車のルートをリストアップする。
　ここで、サービス情報ＤＢ３２１に蓄積されるサービス情報の一例を下記表１および表２に示す。下記表１および表２に示すように、サービス情報には、ライドシェアリングする車に関する情報と、ライドシェアリングのリクエストに関する情報が含まれる。
　ライドシェアリングする車に関する情報には、車ＩＤ毎に、サービス中か空車かの状態、現在地、および状態がサービス中の場合は目的地と到着予定時刻が含まれる。また、リクエストに関する情報には、リクエストＩＤ毎に、ユーザＩＤ、時刻、現在地、および目的地が含まれる。
Figure JPOXMLDOC01-appb-T000001
Figure JPOXMLDOC01-appb-T000002
　サービス提供サーバ３は、ルートのリストアップと共に、各ルートの料金、乗車時刻、降車予定時刻、および相乗り人数を算出してもよい。ここで、リストアップしたルートの一例を図１０に示す。図１０に示す例は、例えばユーザＵ２からリクエストがあった場合にリストアップしたルートである。図１０に示すように、ルート１は、ユーザＵ１、ユーザＵ２、およびユーザＵ３が同乗するルート、ルート２は、ユーザＵ２、ユーザＵ３、およびユーザＵ４が同乗するルート、ルート３は、ユーザＵ２およびユーザＵ３が同乗するルートである。各ルートには、各ユーザの乗車位置および降車位置が示されている。
　通常マッチングにおいてこのようにルートがリストアップされた場合、従来は、図１１に示すような選択画面５０がユーザ端末１に表示される。選択画面５０には、各ルートの料金、乗車時刻、降車予定時刻、および相乗り人数と、決定ボタンと、キャンセルボタンが表示されている。ユーザは（Ｕ２）は、かかる情報に基づいて任意のルートを選択していた。
　しかしながら、従来のサービスシステムでは、ライドシェアする他ユーザとの相性が考慮されていないため、快適に過ごせない可能性も高かった。
　そこで、本実施例では、相性マッチング結果を考慮し、図１２に示すようにルート毎に同乗者との相性度も提示した選択画面５１を提示する。これにより、ユーザは料金や時間、相乗り人数と共に、快適にライドシェアリングできるか否かを左右する同乗者との相性度も考慮してルートを選択することが可能となる。
　サービス提供サーバ３は、このようなルート毎（車毎）の相性度を算出するために、各ルートにおけるユーザと同乗者との相性度を相性管理サーバ２から取得する。
　具体的には、まず、サービス提供サーバ３は、一のルートの同乗者（例えばルート１の場合、「ユーザＵ１、ユーザＵ２、およびユーザＵ３」）を選択する（ステップＳ２０６）。選択された同乗者のＩＤは、相性リクエストに含めて相性管理サーバ２に送信される。
　次いで、相性管理サーバ２は、リクエストされた同乗者間の相性情報が相性情報ＤＢ２２２に蓄積済みか否かを判断する（ステップＳ２０９）。蓄積済みの場合には、過去に同乗したときの相性度を用いることができるためである。相性管理サーバ２は、ユーザＩＤに基づいてユーザ情報ＤＢ２２１に格納されるユーザ情報を参照し、リクエストされた同乗者間の相性情報が存在するか否かを判断する。ここで、ユーザ情報ＤＢ２２１に格納されるユーザ情報の一例を下記表３に示す。
Figure JPOXMLDOC01-appb-T000003
　上記表３に示すように、ユーザ情報は、ユーザＩＤ、名前、性格類型、および相性情報を含む。「相性情報」は、過去に同乗した他ユーザとの相性情報が、同乗した相手ユーザ毎に、相性ＩＤのリストとして記載されている。例えば、上記表３では、ユーザＵ１は、ユーザＵ２と１回、ユーザＵ６と２回、同乗したことが分かる。
　ユーザ情報ＤＢ２２１に蓄積済みの場合（ステップＳ２０９／Ｙｅｓ）、相性管理サーバ２は、相性ＩＤに基づいて相性情報ＤＢ２２２から共有者個人間の相性度を取得し、サービス提供サーバ３に返信する（ステップＳ２１２）。
　一方、ユーザ情報ＤＢ２２１に蓄積されていない場合（ステップＳ２０９／Ｎｏ）、過去に同乗したことがないため、相性管理サーバ２は、共有者の性格類型に基づいて相性度を取得し、サービス提供サーバ３に返信する（ステップＳ２１５）。
　本実施例において、相性情報ＤＢ２２２に蓄積される「相性情報」には、個人間の相性情報と性格類型間の相性情報がある。ここで、下記表４に、個人間の相性情報の一例を示す。
Figure JPOXMLDOC01-appb-T000004
　個人間の相性情報は、相性ＩＤ、日時（シェアリングサービスの利用日時等）、ユーザＩＤ（本人）、共有者のユーザＩＤ（相手）、および算出された相性度を含む。相手との相性は必ずしも対称ではないため、双方からの相性情報がそれぞれ蓄積される。例えば、ユーザＵ１とユーザＵ２がライドシェアした際、ユーザＵ１のユーザＵ２との相性度は「0.8」で楽しく過ごしたことが分かるが、ユーザＵ２のユーザＵ１との同乗の相性度は「0.1」で不快であったことが分かる。なお相性管理サーバ２は、日時情報を参照し、最新のデータを優先的に取得するようにしてもよい。
　一方、性格類型間の相性情報は、過去に同乗したことのない相手との相性を取得する際に用いられるものであって、ある性格類型に対する各性格類型の標準的な相性度が示される。ここで、下記表５に性格類型間の相性情報の一例を示す。性格類型の詳細については後述するが、例えば４つの性格類型（00、01、10、11）の間の相性度が記述されており、これらは個人間相性情報に基づいて修正（更新）されてもよい。
Figure JPOXMLDOC01-appb-T000005
　そして、同乗者の選択が終了すると（すなわち全ての同乗者の相性度を相性管理サーバ２から取得すると）（ステップＳ２１８／Ｙｅｓ）、サービス提供サーバ３は、相性度を考慮してルート毎のマッチング結果を出力する（ステップＳ２２１）。例えばサービス提供サーバ３は、ルート毎の全ての同乗者（シェアする相手）の相性度を平均し、図１２に示すようにルート毎の相性度として提示してもよい。なお、相性度を考慮したルート毎のマッチング結果は、相性管理サーバ２が算出してもよい。
　ここで、ルート毎の相性度の算出について具体例を用いて説明する。
　例えばユーザＵ２のリクエストに応じてリストアップされたルート１（図１０参照）の場合、同乗者はユーザＵ１とユーザＵ３になる。ユーザＵ２のユーザＵ１との相性度は、上記表３および表４に示すように、「0.1」であることが分かる。また、ユーザＵ２のユーザＵ３との相性度は表４の相性情報に存在しないため、性格類型に基づいて推定される。例えばユーザＵ２の性格類型が「01」であって、ユーザＵ３の性格類型が「11」の場合、上記表５を参照すると、ユーザＵ２のユーザＵ３との相性度は「0.3」であることが分かる。
　ルート１の相性度は、これらの平均に基づいて「0.2」と算出される。
　　ルート１相性度=(0.1+0.3)/2=0.2
　また、ルート２の相性度は、ユーザＵ４の性格類型が例えば「01」の場合、ユーザＵ２のユーザＵ４との相性度は「0.5」となるため、相性度の平均は「0.4」となる。
　　ルート２相性度=(0.3+0.5)/2=0.4
　同様に、ルート３の相性度は、「0.3」となる。
　　ルート３相性度=(0.3)/1=0.3
　なお、上述した例では、一例として同乗者との組合せのみから相性度を算出したが、相性度が低い場合であっても、同乗距離が短い場合（すなわち、同乗時間が短い場合）は、同乗距離が長い場合よりも不快さが軽減されることが推定される。
　従って、例えば距離による重み付けを行って相性度を算出してもよい。
　具体例としては、例えばルート１のユーザＵ２の乗車距離を1.0として、ユーザＵ１との相乗り距離が0.4、ユーザＵ３との相乗り距離が1.0の場合、ルート１の相性度は「0.17」と算出される。
　　ルート１相性度=(0.1*0.4+0.3*1.0)/2=0.17
　また、例えばルート２のユーザＵ３との相乗り距離が0.8、ユーザＵ４との相乗り距離が0.6の場合、ルート２の相性度は「0.47」と算出される。
　　ルート２相性度=(0.3*0.8+0.5*0.6)/2=0.27
　また、ルート３のユーザＵ３との相乗り距離が1.0の場合、ルート３の相性度は「0.3」と参照される。
　　ルート３相性度=(0.3*1.0)/1=0.3
　以上、各ルートの相性度について、単純に平均して算出する方法と、距離に応じた重み付けを行って算出する方法について説明した。なお本実施例による算出方法はこれに限定されず、例えば、同性が良いなど性別に応じた重み付けを行って算出する方法や、隣の席は嫌など席の位置や距離に応じた重み付けを行って算出する方法や、二人きりは嫌など相乗り人数に応じた重み付けを行って算出する方法であってもよい。また、これらを適宜組み合わせて算出してもよい。これにより、例えば、ユーザと比較的相性が合わないと推定される他のユーザと同じ時間帯に同じ車をシェアするようなサービスを提供する必要があるときには、更に別のユーザも同乗してもらうような利用スケジュールをサービス提供情報として提供することも可能である。また、ユーザと比較的相性が合わないと推定される他のユーザとは隣同士にならないような利用スケジュールをサービス提供情報として提供することも可能である。
　（４－１－２．性格類型の推定処理）
　続いて、本実施例による性格類型の推定処理について図１３～図１４を参照して説明する。性格類型の推定は、例えばサービス利用中にユーザをセンシングしたセンサデータに基づいて行われる。
　（性格類型）
　ここで、まず、本実施例による「性格」の定義について説明する。人の性格を説明する際には、例えば類型論と特性論の２つの考え方が用いられる。類型論では性格をいくつかの典型的な類型で説明し、特性論では性格をいくつかの特性の組合せとして説明する。また、広義の性格であるパーソナリティを、先天的な気質と後天的な性格に分類することもある。本実施例では、一例として、クロニンジャー(Robert　Cloninger)の特性論であるパーソナリティ理論を用いる。
　かかるパーソナリティ理論では、４つの気質パラメータ「新規性探究、報酬依存、損害回避、固執」と３つの性格パラメータ「自己志向性、協調性、自己超越性」の合計７つの特性から性格を分類する（所謂、パーソナリティ７次元モデル）。
　気質パラメータのそれぞれの特徴と神経伝達物質との関連性については、新規性探究が神経伝達物質のドーパミンと関連し、報酬依存がノルエピネフリンと関連し、損害回避がセロトニンと関連するといった研究がなされている。
　本実施例では、新規性探究、報酬依存、損害回避といった３つの気質パラメータを軸とし、図１３に示すような３次元空間を想定して、新規性探究、報酬依存、損害回避のそれぞれの軸を０～１に正規化して下記の８つの性格類型を定義する。
　・性格タイプ000－新規性探究、報酬依存、及び損害回避が低い「独立」タイプ
　・性格タイプ001－新規性探究及び報酬依存が低く、損害回避が高い「論理的」タイプ
　・性格タイプ011－新規性探究が低く、報酬依存及び損害回避が高い「慎重」タイプ
　・性格タイプ111－新規性探究、報酬依存、及び損害回避が高い「神経質」タイプ
　・性格タイプ010－新規性探究及び損害回避が低く、報酬依存が高い「生真面目」タイプ
　・性格タイプ110－新規性探究及び報酬依存が高く、損害回避が低い「情熱家」タイプ
　・性格タイプ100－新規性探究が高く、報酬依存及び損害回避が低い「冒険家」タイプ
　・性格タイプ101－新規性探究及び損害回避が高く、報酬依存が低い「激情家」タイプ
　なお、以降では説明を簡単にするために、報酬依存と損害回避の２軸からなる下記の４つのタイプを用いて説明する。
　・性格タイプ00－報酬依存及び損害回避が低いタイプ
　・性格タイプ01－報酬依存が低く、損害回避が高いタイプ
　・性格タイプ11－報酬依存及び損害回避が高いタイプ
　・性格タイプ10－損害回避が低く、報酬依存が高いタイプ
　（推定処理）
　図１４は、本実施例による性格類型の推定処理を示すフローチャートである。図１４に示すように、まず、相性管理サーバ２は、サービス利用中の各ユーザのセンサデータを取得すると、同乗者の組み合わせを選択し（ステップＳ３０３）、選択した組み合わせにおけるパラメータをセンサデータから算出する（ステップＳ３０６）。センサデータから算出するパラメータは、例えば、カメラにより乗車中に撮像された撮像画像から算出される笑顔時間、笑顔共起時間、閉眼時間等、またはマイクロホンにより乗車中に収音された音声データから算出された発話時間や発話時間比率等、また、脈拍センサから検知された脈拍値に基づく脈拍平均値や脈拍変化値等が想定される。詳細については後述する。
　次いで、相性管理サーバ２は、上記パラメータに基づいて、性格類型パラメータを算出する（ステップＳ３０９）。性格類型パラメータは、性格タイプを判断するためのパラメータであって、ここでは一例として「報酬依存」と「損害回避」を算出する。詳細については後述する。
　そして、上記ステップＳ３０３～Ｓ３０９に示す処理を、全ての同乗者の組み合わせに対して行う（ステップＳ３１２）。例えばユーザ２が、ユーザＵ１およびユーザＵ３と同乗した場合、ユーザ２がユーザＵ１と乗車している間における各種パラメータ（笑顔時間等）をセンサデータから算出し、性格類型パラメータを算出する。さらに、ユーザ２がユーザＵ３と乗車している間における各種パラメータ（笑顔時間等）もセンサデータから算出し、性格類型パラメータを算出する。
　また、ユーザ１がユーザＵ２と乗車している間における各種パラメータ（笑顔時間等）をセンサデータから算出し、性格類型パラメータを算出する。さらに、ユーザ１がユーザＵ３と乗車している間における各種パラメータ（笑顔時間等）もセンサデータから算出し、性格類型パラメータを算出する。
　また、ユーザ３がユーザＵ１と乗車している間における各種パラメータ（笑顔時間等）をセンサデータから算出し、性格類型パラメータを算出する。さらに、ユーザ３がユーザＵ１と乗車している間における各種パラメータ（笑顔時間等）もセンサデータから算出し、性格類型パラメータを算出する。
　このように、３人が同乗している場合は、３組（ユーザ２とユーザ１、ユーザ２とユーザ３、ユーザ１とユーザ３）の組み合わせにおいて、双方のパラメータの算出と性格類型パラメータの算出が行われる。
　次に、相性管理サーバ２は、一の同乗者を選択し（ステップＳ３１５）、当該同乗者において、上記算出した性格類型パラメータに基づいて性格類型を推定し（ステップＳ３１８）、ユーザ情報ＤＢ２２１に蓄積されている各ユーザの性格類型を修正（更新）する（ステップＳ３２１）。
　そして、相性管理サーバ２は、全ての同乗者を選択して性格類型の推定、修正を行うまで上記ステップＳ３１５～ステップＳ３２１の処理を繰り返す（ステップＳ３２４）。
　・センサデータからのパラメータの算出
　続いて、上記ステップＳ３０６に示すパラメータ算出について詳述する。本実施例では、例えば乗車中における笑顔時間、笑顔時間変化、笑顔共起時間、閉眼時間、発話時間、発話時間比率、心拍数（平均値等）、心拍数変化等が、センサ群４（カメラ、マイク、脈拍センサなど）によるセンサデータから算出される。
　例えば、ユーザＵ２が上述したルート１を選択し、ユーザＵ１、ユーザＵ２、およびユーザＵ３の３名が同乗した場合、下記のようにパラメータが算出される。
Figure JPOXMLDOC01-appb-T000006
　ユーザＵ１が同乗者（ユーザＵ２）と同乗した時間において、「笑顔時間」はユーザＵ１がどれくらいの時間に笑顔になっていたか、「笑顔共起時間」はユーザＵ１とユーザＵ２がどれくらい一緒に笑顔になっていたかである。また、「閉眼時間」はユーザＵ１がどれくらいの時間「寝たふり」のように目を閉じていたか、「発話時間」はユーザＵ１がどれくらいの時間喋っていたかである。
　また、「発話時間比率」はユーザＵ１とユーザＵ２の発話の比率、「心拍数」はユーザＵ１の平均心拍数である。また、「笑顔時間変化」と「心拍数変化」（不図示）は、同乗した時間の前半と後半での増減である。
　なお、各パラメータは０～１に正規化され、時間のパラメータは同乗時間で正規化され、心拍数などの生理データは各人の最小値と最大値により正規化される。
　ここで、「笑顔時間変化」について詳述する。まず、ユーザＵ１が同乗者（ユーザＵ２）と同乗していた時間Ｔは、図１５に示すように求められる。すなわち、例えばユーザＵ２が先に乗車していてユーザＵ１が相乗りし、ユーザＵ２が先に降りた場合、図１５に示すように、ユーザＵ１とユーザＵ２が同乗していた時間Ｔとなる。
　このときのユーザＵ１の笑顔度の時間変化のグラフを図１６に示す。図１６に示すように、同乗時間Ｔの前半(0<t≦T/2)で笑顔度が笑顔閾値Ｓｔｈを超えた時間をＴＳＦＨ、後半(T/2<t≦T)で笑顔度が笑顔閾値Ｓｔｈを超えた時間をＴＳＳＨとすると、笑顔時間変化（ΔＴＳ）は例えば下記式１により求められる。
Figure JPOXMLDOC01-appb-M000007
　これにより、例えば前半は継続して笑っていたが後半は全く笑わないときに１、前半全く笑わず後半は継続して笑ったときに0となる。すなわち、前半は継続して笑っていたが後半は全く笑わないときは、前半は人との関係性を損ねないように無理に笑っていたと考えられるため、後半に笑顔が減ったことが、行為の抑制を表す「損害回避」において正に評価される。
　また、ユーザＵ１の心拍数の時間変化のグラフを図１７に示す。図１７に示すように、同乗時間(0<t≦T)の平均心拍数をＨＲａｖｒ、安静時心拍数をＨＲ０とすると、正規化された心拍数ＨＲは例えば下記式２により求められる。
Figure JPOXMLDOC01-appb-M000008
  
 
　・性格類型パラメータの算出
　次いで、上述したように算出されたパラメータに基づく性格類型パラメータの算出について詳述する。本実施例では、性格類型を判断するための性格類型パラメータである「報酬依存ＲＤ」および「損害回避ＨＡ」を、例えば下記式３により求める。
Figure JPOXMLDOC01-appb-M000009
Figure JPOXMLDOC01-appb-I000010
　そして、算出した報酬依存ＲＤと損害回避ＨＡを用いて、下記の条件から性格類型（性格タイプ）が判断される。
　　0≦RD<0.5　かつ　0≦HA<0.5　ならば、性格タイプ00
　　0≦RD<0.5　かつ　0.5≦HA≦1.0　ならば、性格タイプ01
　　0.5≦RD≦1.0　かつ　0≦HA<0.5　ならば、性格タイプ10
　　0.5≦RD≦1.0　かつ　0.5≦HA≦1.0　ならば、性格タイプ11
　より具体的には、例えばユーザＵ１が同乗者：ユーザＵ２と同乗した時間におけるユーザＵ１の報酬依存ＲＤＵ２は、例えば、
RDU2=0.5TSU1U2+0.5TCSU1U2+(-0.5)TCEU1U2+0.5TUU1U2
となる。
　つまり、報酬依存は社交的か否かというような「人との関係性」を表すので、例えば笑顔時間、笑顔共起時間、および発話時間に基づいて正に評価され、閉眼時間のように人との関係を遮断する行為によって負に評価される。
　同様に、ユーザＵ１が同乗者：ユーザＵ２と同乗した時間におけるユーザＵ１の損害回避ＨＡＵ２は、例えば、
HAU2=0.5ΔTSU1U2+0.5HRU1U2
となる。
　つまり、損害回避は心配性か否かというような「行為の抑制」を表すので、例えば笑顔時間変化や心拍数によって笑顔が少なくなったことや心拍数が高くなったことが正に評価される。例えば笑顔時間変化において、同乗時間のうち前半より後半の方が笑顔時間が少ない場合、前半は人との関係性を損ねないように無理に笑っていたと考えられ、後半に笑顔が減ったことが正に評価される。また、心拍数が通常よりも高い場合、他の人と乗り合わせることにより不安を感じていると考えられるため、正に評価される。
　以上、本実施例では、過去のサービス利用時の情報（センサデータ）に基づいて性格類型を推定しているが、ユーザがサービスを利用し始めた初期段階等、ユーザの性格類型を推定できない場合もあるため、サービス加入時に性格類型を推定できるアンケート等をユーザ入力してもらってもよい。
　例えば、アンケートは下記のような設問から成り、相性管理サーバ２は、下記設問の回答に基づいてユーザの性格類型を推定することができる。
　アンケートの設問例：
（１）たいていの人なら時間の無駄だと思うようなことでも、興味やスリルのために新しいことをやってみることが多い　＜はい／いいえ＞
（２）たいていの人が心配するような状況でも、万事好調に行くという自信がある　＜はい／いいえ＞
（３）立派な演説や詩に深く心を打たれることが多い　＜はい／いいえ＞
　なお、上記設問（１）は新規性追求、設問（２）は損害回避、設問（３）は報酬依存に関するものであり、新規性探求、損害回避、報酬依存の全ての設問の「はい／いいえ」に基づき、それぞれの軸の「０／１」を決定し、性格類型を求める。
　（４－１－３．相性度の算出処理）
　続いて、本実施例による相性度の算出処理について図１８を参照して説明する。相性度の算出は、例えばサービス利用中にユーザをセンシングしたセンサデータに基づいて算出され得る。
　図１８は、本実施例による相性度の算出処理を示すフローチャートである。図１８に示すように、まず、相性管理サーバ２は、サービス利用中の各ユーザのセンサデータを取得すると、同乗者の組み合わせを選択し（ステップＳ３３３）、選択した組み合わせにおけるパラメータをセンサデータから算出する（ステップＳ３３６）。
　センサデータから算出するパラメータは、上述した性格類型推定で用いたパラメータと同様に、例えば、カメラにより乗車中に撮像された撮像画像から算出される笑顔時間、笑顔共起時間、閉眼時間等、またはマイクロホンにより乗車中に収音された音声データから算出された発話時間や発話時間比率等、また、脈拍センサから検知された脈拍値に基づく脈拍平均値や脈拍変化値等が想定される。これらのパラメータの算出の詳細については、性格類型推定時の同パラメータの算出と同様であるため、ここでの詳細な説明は省略する。
　次に、相性管理サーバ２は、パラメータに基づいて選択した組み合わせにおける相性度を算出し（ステップＳ３３９）、相性情報ＤＢ２２２に蓄積されている各ユーザの相性度を修正（更新）する（ステップＳ３４２）。なお、相性管理サーバ２は、ユーザ同士の相性を修正した際、対応する性格類型間の相性情報も修正（更新）するようにしてもよい。相性度算出の詳細については後述する。
　そして、相性管理サーバ２は、全ての同乗者の組み合わせについて上記ステップＳ３３３～Ｓ３４２の処理を繰り返す（ステップＳ３４５）。
　・相性度の算出
　次いで、上記ステップＳ３３９に示す相性度の算出について具体例を用いて説明する。本実施例では、例えば下記式４により、ｘからｙへの相性度を算出し得る。
Figure JPOXMLDOC01-appb-M000011
　一例として、ユーザＵ２が上述したルート１を選択し、ユーザＵ１、ユーザＵ２、ユーザＵ３の３名が同乗した場合の相性度の算出について説明する。ここでは、上述した表６に示すパラメータを用いる。
　この場合、ユーザＵ１がユーザＵ２と同乗した時間におけるユーザＵ１のユーザＵ２との相性度は、例えば、
相性度U1U2=0.3TSU1U2+0.6TCSU1U2+(-0.8)TCEU1U2+0.3TUU1U2+0.6RUU1U2
となる。
　つまり、相性度は、笑顔時間、笑顔共起時間、発話時間、および発話時間比率によって正に評価され、閉眼時間によって負に評価される。なお、ユーザＵ１とユーザＵ２の発話時間比率は下記式５で表され、バランスよく両者が等しく喋ったときに1となるようにしてもよい。
Figure JPOXMLDOC01-appb-M000012
　このように、ユーザＵ１がユーザＵ２と同乗しているときに笑顔が多かったり、一緒に笑顔になったり、寝たふりをすることがなく喋ることが多くなってユーザ２と同じぐらい喋っているときに、相性度が高くなる。
　なお、本実施例で用いたパラメータ（笑顔時間、笑顔共起時間、発話時間、発話時間比率、および閉眼時間等）は、乗車中継続的に測定される。しかし、本実施例で用いるパラメータは乗車中継続的に測定されるものに限定されず、乗車中の特定のイベントに紐付いたものであってもよい。例えば、「急加減速笑顔時間」のように、乗車中の急加速や急減速を楽しむかどうかや、「渋滞中笑顔時間」のように、乗車中に渋滞に巻き込まれたときにネガティブな感情になるのではなく楽しめるかどうかなどのパラメータを導入することも可能である。また、これら「急加減速笑顔時間」や「渋滞中笑顔時間」といった乗車中の特定のイベントに紐付くパラメータは、性格類型推定の際に用いることも可能である。この場合、さらに「急加減速笑顔共起時間」や「渋滞中笑顔共起時間」を用いてもよい。
　＜４－２．第２の実施例＞
　次に、本実施形態による第２の実施例について説明する。上述した第１の実施例では、相性情報を同じシェアサービスの相性マッチングに利用していたが、本実施形態はこれに限定されず、あるシェアリングサービスを利用したときの相性情報を、他のシェアリングサービスにおける相性マッチングに利用することも可能である。
　より具体的には、例えばルームシェアリングサービスの利用者から取得した相性情報を、映画館の座席推薦サービスに応用することが可能である。相性管理サーバ２は、ルームシェアリングサービスを提供するサービス提供サーバ３Ｂからサービス利用中のユーザのセンサデータを取得して相性情報を生成、蓄積し、映画館の座席推薦サービスを提供するサービス提供サーバ３Ｃ（座席予約管理サーバ）からのリクエストに応じて、蓄積した相性情報に基づいて相性マッチングを行うことが可能である。
　なおサービス提供サーバ３Ｂは、ルームシェアリングサービスにおける相性マッチングを行うことが可能である。例えば上述した実施例１のライドシェアサービスにおける「同乗者」を「同居者」に置き換えることで同様に相性度の算出および相性マッチングを実現できる。
　ここで、ルームシェアリングサービスを提供する場合のサービス提供サーバ３Ｂに格納されるサービス情報の一例を下記表７および表８に示す。サービス情報には、各部屋に関する情報と、各ユーザからのリクエストに関する情報が含まれる。
Figure JPOXMLDOC01-appb-T000013
Figure JPOXMLDOC01-appb-T000014
　上記表７に示すように、部屋に関する情報には、サービスＩＤ、名称、所在地、料金、状態（満／空）、および空き情報を含む。空き情報には、部屋ごとに同居しているユーザＩＤが示される。
　また、上記表８に示すように、リクエスト情報には、リクエストＩＤ、リクエストしたユーザＩＤ、リクエストした内容情報が含まれる。内容情報には、ユーザが希望する地域や料金が示される。
　なお、ユーザ情報や相性情報（個人間相性情報、性格類型間相性情報）のデータ構成は、第１の実施例と同様である。
　また、映画館の座席推薦サービスを提供するサービス提供サーバ３Ｃに格納されるサービス情報の一例を下記表９および表１０に示す。サービス情報には、各映画館に関する情報と、各ユーザからのリクエストに関する情報が含まれる。
Figure JPOXMLDOC01-appb-T000015
Figure JPOXMLDOC01-appb-T000016
　上記表９に示すように、映画館に関する情報には、サービスＩＤ、名称、所在地、料金、状態（満／空）、および空き情報を含む。空き情報には、座席毎に予約したユーザＩＤが示される。
　また、上記表１０に示すように、リクエスト情報には、リクエストＩＤ、リクエストしたユーザＩＤ、リクエストした内容情報が含まれる。内容情報には、ユーザが希望する地域と上映タイトルと上映時刻が示される。
　なお、ユーザ情報や相性情報（個人間相性情報、性格類型間相性情報）のデータ構成は、第１の実施例と同様である。
　（ルームシェアリングの相性マッチング）
　また、本実施例によるルームシェアリングの相性マッチングの動作処理は、図９に示すライドシェアリングの相性マッチングの動作処理における「同乗者」を「同居者」に読み替えたものと同様である。
　すなわち、サービス提供サーバ３Ｂは、ユーザからルームシェアリングのリクエストがあると、通常のマッチングの処理として、リクエストのユーザＩＤ、希望する地域、および料金に基づいて、希望する地域に所在地があり、かつ空室のある部屋をリストアップする。従来は、リストアップした各部屋について「名称、所在地、料金、同居人数」をユーザに提示する画面を提示していたが、本実施例では、さらに相性マッチングに基づいて各部屋の同居者との相性を示す「相性度」も提示することが可能である。
　また、相性管理サーバ２は、第１の実施例と同様に、サービス利用中のユーザのセンシングデータに基づいて、性格類型の推定や相性度の算出が可能である。同居中のセンシングデータは、プライバシーを考慮する場合は共有スペースのみでセンシングを行うようにしてもよい。センシングデータから算出するパラメータも、上述した例と同様に、笑顔時間、笑顔共起時間、閉眼時間、発話時間、発話時間比率、脈拍値、脈拍変化値等が想定される。
　（座席推薦サービスへの応用）
　続いて、相性情報を他のシェアリングサービスへ応用する場合について説明する。
　まず、映画館の座席推薦サービスを提供するサービス提供サーバ３Ｃは、ユーザから映画鑑賞のリクエストがあると、通常のマッチング処理を行う。すなわち、サービス提供サーバ３Ｃは、リクエストのユーザＩＤ、希望する地域、タイトル、および時刻に基づいて、希望する地域に所在地があり、かつ空席のある映画館をリストアップする。
　従来は、リストアップした各映画館について「名称、所在地、料金、空席リスト」をユーザに提示する画面を提示していたが、本実施例では、さらに相性マッチングに基づいて、例えば周辺に同席する他ユーザとの相性に基づく「相性度」も提示することが可能である。
　ここで、図１９に、従来のマッチングによる座席推薦画面例を示す。図１９に示すように、従来の座席推薦画面５２では、空席か否かの表示しか行われず、周辺のユーザとの相性は考慮されていなかった。
　次いで、本実施例による相性マッチングに基づく座席推薦画面例を図２０に示す。図２０に示すように、本実施例による座席推薦画面５３では、空席毎に周辺の席のユーザとの相性度が算出され、相性度が所定値以上の空席は太線で示され、「お薦めの空席」として明示される。また、既に埋まっている席に関する情報として、相性度に基づいて、「相性の良さそうな人の席」や「相性の悪そうな人の席」も明示するようにしてもよい。
　このような空席の相性度の算出について、図２１を参照して具体的に説明する。
　図２１は、本実施例による空席の相性度の算出について説明する図である。図２１に示すように、ある空席の周囲に席[S1,S2,S3,S4,S5,S6,S7,S8]があり、席[S3,S6,S7]が空席で、他の席には予約したユーザがいる場合を想定する。
　この場合、相性管理サーバ２（若しくはサービス提供サーバ３Ｃ）は、予約したユーザのリスト[U31,U32,U34,U35,U38]からユーザを選択して相性度を求める。リクエストしたユーザと予約したユーザの相性情報が個人間相性情報に存在する場合には、個人間相性情報から相性度を取得し、存在しない場合には、ユーザ情報から取得できるリクエストしたユーザの性格類型と予約したユーザの性格類型を用いて、性格類型間相性情報から相性度を取得する。
　空席の相性度は、例えば上述した周囲の席の相性度の平均として求められる。若しくは、一人でも相性度が所定値（下限値）を下回る人が周囲に居る場合は、当該空席、または当該上映回を薦めないようにしてもよい。
　以上、本実施例では、ルームシェアリングサービスの相性情報を映画鑑賞の座席推薦サービスに応用する例について説明した。
　なお本実施例はこれに限定されず、その他様々なシェアリングサービス間で相性情報を利用することが可能である。例えば、民泊での相性の良い同居者との快適な宿泊を提供するサービス、飛行機や列車などで同席者との相性を考慮した快適な旅行を提供するサービスで利用することも可能である。
　＜＜５．まとめ＞＞
　上述したように、本開示の実施形態による情報処理システムでは、利用者や共有サービス提供者に負担を掛けることなく取得した共有サービス利用者の相性情報に基づいて、様々なサービスリクエストに応えることが可能となる。
　以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本技術はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
　例えば、上述したユーザ端末１、相性管理サーバ２、またはサービス提供サーバ３に内蔵されるＣＰＵ、ＲＯＭ、およびＲＡＭ等のハードウェアに、ユーザ端末１、相性管理サーバ２、またはサービス提供サーバ３の機能を発揮させるためのコンピュータプログラムも作成可能である。また、当該コンピュータプログラムを記憶させたコンピュータ読み取り可能な記憶媒体も提供される。
　また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。
　なお、本技術は以下のような構成も取ることができる。
（１）
　同じ時間帯に同じ空間をシェアしている複数ユーザに対してサービスを提供するサービス業者が運営するサービス情報提供システムにおいて、
　サービス利用中の複数ユーザをセンシングすることにより得られたセンサデータに基づき生成される複数ユーザ間の相性を示す相性情報を記憶する記憶部と、
　ユーザからのサービスリクエストを受信する通信部と、
　前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、前記サービスリクエストに応じたサービス提供情報を、前記通信部を介して提供するように制御する制御部と、
を備える、サービス情報提供システム。
（２）
　前記制御部は、
　　前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、
　　前記サービスリクエストに応じたサービスに関するサービス提供情報に、当該サービスを供に享受する他のユーザとの相性情報も含め、前記通信部を介して、前記ユーザに対して提供するように制御する、前記（１）に記載のサービス情報提供システム。
（３）
　前記制御部は、
　　前記記憶部に、前記ユーザと前記サービスを供に享受する他のユーザとの相性情報が記憶されていない場合、前記ユーザに関する情報に応じて、前記サービスを供に享受する他のユーザとの相性情報を推定する、前記（２）に記載のサービス情報提供システム。
（４）
　前記ユーザに関する情報は、性格類型情報である、前記（３）に記載のサービス情報提供システム。
（５）
　前記サービス情報提供システムは、ライドシェアリングサービスに関するサービス情報を提供し、
　前記記憶部は、ユーザが他のユーザと共にライドシェアリングサービスを利用したときに得られたセンサデータに基づき生成された複数ユーザ間の相性を示す相性情報を記憶し、
　前記制御部は、
　　前記通信部が前記ユーザから同じライドシェアリングサービスを享受するためのサービスリクエストを受信すると、前記記憶部に記憶される前記ユーザに関連付けられる相性情報から、比較的相性が合わないと推定される他のユーザと同じ時間帯に同じ車をシェアすることがないような利用スケジュールをサービス提供情報として前記ユーザに提供するように制御する、前記（１）～（４）のいずれか１項に記載のサービス情報提供システム。
（６）
　前記制御部は、
　前記サービスリクエストに応えるため、前記ユーザと比較的相性が合わないと推定される他のユーザと同じ時間帯に同じ車をシェアするようなサービスを提供する必要があるときには、更に別のユーザも同乗してもらうような利用スケジュールをサービス提供情報として提供する、前記（５）に記載のサービス情報提供システム。
（７）
　前記制御部は、
　　前記ユーザと、前記他のユーザとは隣同士にならないような利用スケジュールをサービス提供情報として提供する、前記（５）に記載のサービス情報提供システム。
（８）
　前記制御部は、
　　前記記憶部に既に記憶されている、前記サービスリクエストがあったサービスとは異なるサービスを過去に利用したときの前記ユーザと他のユーザとの相性情報を踏まえて、前記サービスリクエストに応じたサービス提供情報を、前記通信部を介して提供するように制御する、前記（１）～（７）のいずれか１項に記載のサービス情報提供システム。
（９）
　同じ時間帯に同じ空間をシェアしている複数ユーザに対してサービスを提供するサービス業者が運営するサービス情報提供サーバに、当該サービスを利用する複数ユーザ間の相性情報を提供するサービス情報提供システムにおいて、
　サービス利用中の複数ユーザをセンシングすることにより得られたセンサデータに基づき生成される複数ユーザ間の相性を示す相性情報を記憶する記憶部と、
　前記サービス情報提供サーバを介して、ユーザからのサービスリクエストに対応する当該ユーザと、当該ユーザと供に同サービスを享受する他のユーザを識別する情報を受信する通信部と、
　前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、前記ユーザと、当該サービスを供に享受する他のユーザとの相性情報を、前記通信部を介して前記サービス情報提供サーバに提供するように制御する制御部と、
を備える、サービス情報提供システム。
（１０）
　前記制御部は、
　　前記記憶部に既に記憶されている、他のサービス情報提供サーバに関連するサービスを過去に利用したときの前記ユーザと他のユーザとの相性情報を踏まえて、前記ユーザと当該サービスを供に享受する他のユーザとの相性情報を、前記通信部を介して前記サービス情報提供サーバに提供するように制御する、前記（９）に記載のサービス情報提供システム。
（１１）
　同じ時間帯に同じ空間をシェアしている複数ユーザに対してサービスを提供するサービス業者が運営するサービス情報提供システムの制御方法において、
　プロセッサが、
　サービス利用中の複数ユーザをセンシングすることにより得られたセンサデータに基づき生成される複数ユーザ間の相性を示す相性情報を記憶部に記憶することと、
　ユーザからのサービスリクエストを通信部により受信することと、
　前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、前記サービスリクエストに応じたサービス提供情報を、前記通信部を介して提供するように制御することと、
を含む、制御方法。
（１２）
　同じ時間帯に同じ空間をシェアしている複数ユーザに対してサービスを提供するサービス業者が運営するサービス情報提供サーバに、当該サービスを利用する複数ユーザ間の相性情報を提供するサービス情報提供システムの制御方法において、
　プロセッサが、
　サービス利用中の複数ユーザをセンシングすることにより得られたセンサデータに基づき生成される複数ユーザ間の相性を示す相性情報を記憶部に記憶することと、
　前記サービス情報提供サーバを介して、ユーザからのサービスリクエストに対応する当該ユーザと、当該ユーザと供に同サービスを享受する他のユーザを識別する情報を通信部により受信することと、
　前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、前記ユーザと、当該サービスを供に享受する他のユーザとの相性情報を、前記通信部を介して前記サービス情報提供サーバに提供するように制御することと、
を含む、制御方法。
　１　　ユーザ端末
　２　相性管理サーバ
　３　サービス提供サーバ
　１０　制御部
　１１　通信部
　１２　入力部
　１３　出力部
　１４　記憶部
　２０　制御部
　２１　通信部
　２２　記憶部
　３０　制御部
　３１　通信部
　３２　記憶部

Claims (12)

  1. 　同じ時間帯に同じ空間をシェアしている複数ユーザに対してサービスを提供するサービス業者が運営するサービス情報提供システムにおいて、
    　サービス利用中の複数ユーザをセンシングすることにより得られたセンサデータに基づき生成される複数ユーザ間の相性を示す相性情報を記憶する記憶部と、
    　ユーザからのサービスリクエストを受信する通信部と、
    　前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、前記サービスリクエストに応じたサービス提供情報を、前記通信部を介して提供するように制御する制御部と、
    を備える、サービス情報提供システム。
  2. 　前記制御部は、
    　　前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、
    　　前記サービスリクエストに応じたサービスに関するサービス提供情報に、当該サービスを供に享受する他のユーザとの相性情報も含め、前記通信部を介して、前記ユーザに対して提供するように制御する、請求項１に記載のサービス情報提供システム。
  3. 　前記制御部は、
    　　前記記憶部に、前記ユーザと前記サービスを供に享受する他のユーザとの相性情報が記憶されていない場合、前記ユーザに関する情報に応じて、前記サービスを供に享受する他のユーザとの相性情報を推定する、請求項２に記載のサービス情報提供システム。
  4. 　前記ユーザに関する情報は、性格類型情報である、請求項３に記載のサービス情報提供システム。
  5. 　前記サービス情報提供システムは、ライドシェアリングサービスに関するサービス提供情報を提供し、
    　前記記憶部は、ユーザが他のユーザと共にライドシェアリングサービスを利用したときに得られたセンサデータに基づき生成された複数ユーザ間の相性を示す相性情報を記憶し、
    　前記制御部は、
    　　前記通信部が前記ユーザから同じライドシェアリングサービスを享受するためのサービスリクエストを受信すると、前記記憶部に記憶される前記ユーザに関連付けられる相性情報から、比較的相性が合わないと推定される他のユーザと同じ時間帯に同じ車をシェアすることがないような利用スケジュールをサービス提供情報として前記ユーザに提供するように制御する、請求項１に記載のサービス情報提供システム。
  6. 　前記制御部は、
    　前記サービスリクエストに応えるため、前記ユーザと比較的相性が合わないと推定される他のユーザと同じ時間帯に同じ車をシェアするようなサービスを提供する必要があるときには、更に別のユーザも同乗してもらうような利用スケジュールをサービス提供情報として提供する、請求項５に記載のサービス情報提供システム。
  7. 　前記制御部は、
    　　前記ユーザと、前記他のユーザとは隣同士にならないような利用スケジュールをサービス提供情報として提供する、請求項５に記載のサービス情報提供システム。
  8. 　前記制御部は、
    　　前記記憶部に既に記憶されている、前記サービスリクエストがあったサービスとは異なるサービスを過去に利用したときの前記ユーザと他のユーザとの相性情報を踏まえて、前記サービスリクエストに応じたサービス提供情報を、前記通信部を介して提供するように制御する、請求項１に記載のサービス情報提供システム。
  9. 　同じ時間帯に同じ空間をシェアしている複数ユーザに対してサービスを提供するサービス業者が運営するサービス情報提供サーバに、当該サービスを利用する複数ユーザ間の相性情報を提供するサービス情報提供システムにおいて、
    　サービス利用中の複数ユーザをセンシングすることにより得られたセンサデータに基づき生成される複数ユーザ間の相性を示す相性情報を記憶する記憶部と、
    　前記サービス情報提供サーバを介して、ユーザからのサービスリクエストに対応する当該ユーザと、当該ユーザと供に同サービスを享受する他のユーザを識別する情報を受信する通信部と、
    　前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、前記ユーザと、当該サービスを供に享受する他のユーザとの相性情報を、前記通信部を介して前記サービス情報提供サーバに提供するように制御する制御部と、
    を備える、サービス情報提供システム。
  10. 　前記制御部は、
    　　前記記憶部に既に記憶されている、他のサービス情報提供サーバに関連するサービスを過去に利用したときの前記ユーザと他のユーザとの相性情報を踏まえて、前記ユーザと当該サービスを供に享受する他のユーザとの相性情報を、前記通信部を介して前記サービス情報提供サーバに提供するように制御する、請求項９に記載のサービス情報提供システム。
  11. 　同じ時間帯に同じ空間をシェアしている複数ユーザに対してサービスを提供するサービス業者が運営するサービス情報提供システムの制御方法において、
    　プロセッサが、
    　サービス利用中の複数ユーザをセンシングすることにより得られたセンサデータに基づき生成される複数ユーザ間の相性を示す相性情報を記憶部に記憶することと、
    　ユーザからのサービスリクエストを通信部により受信することと、
    　前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、前記サービスリクエストに応じたサービス提供情報を、前記通信部を介して提供するように制御することと、
    を含む、制御方法。
  12. 　同じ時間帯に同じ空間をシェアしている複数ユーザに対してサービスを提供するサービス業者が運営するサービス情報提供サーバに、当該サービスを利用する複数ユーザ間の相性情報を提供するサービス情報提供システムの制御方法において、
    　プロセッサが、
    　サービス利用中の複数ユーザをセンシングすることにより得られたセンサデータに基づき生成される複数ユーザ間の相性を示す相性情報を記憶部に記憶することと、
    　前記サービス情報提供サーバを介して、ユーザからのサービスリクエストに対応する当該ユーザと、当該ユーザと供に同サービスを享受する他のユーザを識別する情報を通信部により受信することと、
    　前記記憶部に既に記憶されている前記ユーザと他のユーザとの相性情報を踏まえて、前記ユーザと、当該サービスを供に享受する他のユーザとの相性情報を、前記通信部を介して前記サービス情報提供サーバに提供するように制御することと、
    を含む、制御方法。
PCT/JP2018/013753 2017-06-23 2018-03-30 サービス情報提供システムおよび制御方法 WO2018235379A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/620,971 US20200202474A1 (en) 2017-06-23 2018-03-30 Service information providing system and control method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017-123234 2017-06-23
JP2017123234 2017-06-23

Publications (1)

Publication Number Publication Date
WO2018235379A1 true WO2018235379A1 (ja) 2018-12-27

Family

ID=64736987

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/013753 WO2018235379A1 (ja) 2017-06-23 2018-03-30 サービス情報提供システムおよび制御方法

Country Status (2)

Country Link
US (1) US20200202474A1 (ja)
WO (1) WO2018235379A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020086656A (ja) * 2018-11-19 2020-06-04 トヨタ自動車株式会社 情報処理システム、プログラム、及び情報処理方法
JP2020107215A (ja) * 2018-12-28 2020-07-09 トヨタ自動車株式会社 情報処理装置および移動体システム
CN112243197A (zh) * 2019-07-18 2021-01-19 丰田自动车株式会社 车辆用沟通装置及车辆用沟通系统
JP2021162922A (ja) * 2020-03-30 2021-10-11 トヨタ自動車株式会社 サーバ装置、制御装置、プログラム、車両、及び情報処理システムの動作方法
JP7359095B2 (ja) 2020-07-27 2023-10-11 トヨタ紡織株式会社 移動空間提供システム

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11195245B2 (en) * 2017-12-29 2021-12-07 ANI Technologies Private Limited System and method for allocating vehicles in ride-sharing systems
JP7340771B2 (ja) * 2018-05-28 2023-09-08 パナソニックＩｐマネジメント株式会社 生体検知装置、生体検知方法、記録媒体、およびプログラム
JP7259343B2 (ja) * 2019-01-18 2023-04-18 トヨタ自動車株式会社 配車サービスシステム、配車サービス方法、およびプログラム
US20210110315A1 (en) * 2020-12-22 2021-04-15 Maik Sven FOX Compatibility of ride hailing passengers

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015076028A (ja) * 2013-10-11 2015-04-20 日産自動車株式会社 車両の相乗り者検索システム
WO2016121174A1 (ja) * 2015-01-30 2016-08-04 ソニー株式会社 情報処理システムおよび制御方法
JP2017016343A (ja) * 2015-06-30 2017-01-19 株式会社マーベラス コミュニケーション装置、コミュニケーションシステムおよびコミュニケーションプログラム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3111366B1 (en) * 2014-02-25 2021-11-17 Essity Hygiene and Health Aktiebolag Sensor data analysis for a plurality of users
US20160320195A1 (en) * 2015-04-29 2016-11-03 Ford Global Technologies, Llc Ride-sharing long-term ride-share groups
US9610510B2 (en) * 2015-07-21 2017-04-04 Disney Enterprises, Inc. Sensing and managing vehicle behavior based on occupant awareness
US11049059B2 (en) * 2016-02-03 2021-06-29 Operr Technologies, Inc Method and system for on-demand customized services
US20180089605A1 (en) * 2016-09-23 2018-03-29 Intel Corporation Enhanced ride sharing user experience
US10147325B1 (en) * 2017-02-02 2018-12-04 Wells Fargo Bank, N.A. Customization of sharing of rides

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015076028A (ja) * 2013-10-11 2015-04-20 日産自動車株式会社 車両の相乗り者検索システム
WO2016121174A1 (ja) * 2015-01-30 2016-08-04 ソニー株式会社 情報処理システムおよび制御方法
JP2017016343A (ja) * 2015-06-30 2017-01-19 株式会社マーベラス コミュニケーション装置、コミュニケーションシステムおよびコミュニケーションプログラム

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020086656A (ja) * 2018-11-19 2020-06-04 トヨタ自動車株式会社 情報処理システム、プログラム、及び情報処理方法
JP7155927B2 (ja) 2018-11-19 2022-10-19 トヨタ自動車株式会社 情報処理システム、プログラム、及び情報処理方法
JP2020107215A (ja) * 2018-12-28 2020-07-09 トヨタ自動車株式会社 情報処理装置および移動体システム
JP7028158B2 (ja) 2018-12-28 2022-03-02 トヨタ自動車株式会社 情報処理装置および移動体システム
CN112243197A (zh) * 2019-07-18 2021-01-19 丰田自动车株式会社 车辆用沟通装置及车辆用沟通系统
JP2021018546A (ja) * 2019-07-18 2021-02-15 トヨタ自動車株式会社 車両用コミュニケーション装置および車両用コミュニケーションシステム
JP2021162922A (ja) * 2020-03-30 2021-10-11 トヨタ自動車株式会社 サーバ装置、制御装置、プログラム、車両、及び情報処理システムの動作方法
JP7359095B2 (ja) 2020-07-27 2023-10-11 トヨタ紡織株式会社 移動空間提供システム

Also Published As

Publication number Publication date
US20200202474A1 (en) 2020-06-25

Similar Documents

Publication Publication Date Title
WO2018235379A1 (ja) サービス情報提供システムおよび制御方法
JP6122735B2 (ja) 情報処理装置、判定方法および判定プログラム
US20210005224A1 (en) System and Method for Determining a State of a User
US11269891B2 (en) Crowd-based scores for experiences from measurements of affective response
WO2019116679A1 (ja) 情報処理装置、情報処理方法、およびプログラム
US20220278864A1 (en) Information processing system, information processing device, information processing method, and recording medium
CN110996796B (zh) 信息处理设备、方法和程序
JP6692239B2 (ja) 情報処理装置、情報処理システム、端末装置、情報処理方法及び情報処理プログラム
WO2016181670A1 (ja) 情報処理装置、情報処理方法及びプログラム
US11651238B2 (en) Earpiece advisor
US20220346683A1 (en) Information processing system and information processing method
US11219075B2 (en) Systems and methods for providing a mobility service
JP6552548B2 (ja) 地点提案装置及び地点提案方法
CN110214301B (zh) 信息处理设备、信息处理方法和程序
JP2022145054A (ja) レコメンド情報提供方法及びレコメンド情報提供システム
JP2013222231A (ja) 感情共有コミュニケーション促進システム、感情共有コミュニケーション促進方法、およびプログラム
JP2020086763A (ja) 情報提供装置、情報提供方法、及びプログラム
WO2022249354A1 (ja) 情報処理装置、情報処理システム、情報処理方法及び非一時的なコンピュータ可読媒体
WO2021100515A1 (ja) 情報処理装置、及び情報処理方法
US20230105048A1 (en) Robot control method and information providing method
US11270682B2 (en) Information processing device and information processing method for presentation of word-of-mouth information
CN114556885B (zh) 消息递送
JP2024039954A (ja) 通信システム及び通信方法
JP2022144870A (ja) 情報処理装置、情報処理方法、及び情報処理プログラム

Legal Events

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

Ref document number: 18820885

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: 18820885

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP