Information processing device, information processing method, and program

Abstract

An information processing device according to one embodiment includes: a reception means that receives an API request containing user identification information of a user and service identification information indicating a service from a service infrastructure that provides the service to the user via a whole-body scanner; a first acquisition means that acquires, via a first access means, whole-body data of a category indicated by a first database as being used in the service indicated by the service identification information included in the API request from among whole-body data of the user indicated by the user identification information included in the API request; a second acquisition means that acquires, via a second access means, UI data for displaying, on the whole-body scanner, a menu for the whole-body scanner to provide the service indicated by the service identification information included in the API request; and a transmission means that transmits, to the service infrastructure, an API response including the whole-body data acquired by the first acquisition means and the UI data acquired by the second acquisition means.

Description

Information processing device, information processing method, and program

[0001] The present invention relates to a technique for sharing whole-body data.

[0002] There are known techniques for using data managed by a server on a terminal. For example, Patent Document 1 discloses a technique for transmitting data for outputting a 3D model consisting of specific elements from 3D modeling data managed by a server to an information processing device, which is a terminal.

[0003] Patent No. 6799883

[0004] In a system in which data is shared between a terminal device or the like that uses whole-body data such as 3D data and a server device, an improved technique is provided.

[0005] One aspect of the present disclosure provides an information processing device having: a receiving means for receiving an API request from a service platform that provides a service to a user via a full-body scanner, the API request including user identification information of the user and service identification information indicating the service; a first access means for accessing a first database in which user identification information and whole-body data divided into multiple categories are recorded for each of a plurality of users; a second access means for accessing a second database in which service identification information, a data category to be used, and UI data for providing the service in the full-body scanner are recorded for each of a plurality of services; a first acquisition means for acquiring, via the first access means, whole-body data of a category indicated by the first database to be used for the service indicated by the service identification information included in the API request; a second acquisition means for acquiring, via the second access means, UI data for displaying on the full-body scanner a menu for providing, in the full-body scanner, the service indicated by the service identification information included in the API request; and a transmission means for transmitting to the service platform an API response including the whole-body data acquired by the first acquisition means and the UI data acquired by the second acquisition means.

[0006] The whole body scanner may have multiple types of sensors, and the API response may include information specifying the sensor to be used for the scan performed on the user.

[0007] The receiving means may receive from the whole-body scanner scanner identification information that identifies the whole-body scanner, user identification information of the user, and measurement data measured by the whole-body scanner, and the first access means may write whole-body data obtained from the measurement data to a record in the first database that corresponds to the user identification information.

[0008] In the first database, each whole-body data may be recorded in association with a timestamp indicating the time at which the whole-body data was acquired, the API request may include limitation information that limits the time or place at which the whole-body data was acquired, and the first acquisition means may acquire the whole-body data corresponding to the limitation information from the first database.

[0009] Another aspect of the present disclosure provides an information processing method including the steps of receiving an API request from a service platform that provides a service to a user via a full-body scanner, the API request including user identification information of the user and service identification information indicating the service; accessing a first database in which, for each of a plurality of users, user identification information and whole-body data divided into a plurality of categories are recorded; accessing a second database in which, for each of a plurality of services, service identification information, a data category to be used, and UI data for providing the service in the full-body scanner are recorded; acquiring, via the first access means, whole-body data of the user indicated by the user identification information included in the API request, the whole-body data of a category that is indicated by the first database to be used for the service indicated by the service identification information included in the API request; acquiring, via the second access means, UI data for displaying on the full-body scanner a menu for providing, in the full-body scanner, the service indicated by the service identification information included in the API request; and transmitting an API response to the service platform, the whole-body data acquired by the first acquisition means and the UI data acquired by the second acquisition means.

[0010] Yet another aspect of the present disclosure provides a program for causing a computer to execute the following steps: receiving an API request from a service infrastructure that provides a service to a user via a full-body scanner, the request including user identification information of the user and service identification information indicating the service; accessing a first database in which user identification information and whole-body data divided into multiple categories are recorded for each of a plurality of users; accessing a second database in which service identification information, a data category to be used, and UI data for providing the service in the full-body scanner are recorded for each of a plurality of services; acquiring, via the first access means, whole-body data of the user indicated by the user identification information included in the API request, which belongs to a category indicated by the first database to be used for the service indicated by the service identification information included in the API request; acquiring, via the second access means, UI data for displaying on the full-body scanner a menu for providing, in the full-body scanner, the service indicated by the service identification information included in the API request; and transmitting an API response to the service infrastructure, the whole-body data acquired by the first acquisition means and the UI data acquired by the second acquisition means.

[0011] According to the present invention, an improved technique is provided in a system in which data is shared between a server device and a terminal device that uses whole-body data such as 3D data.

[0012] 1 is a diagram showing an overview of an information processing system 1 according to an embodiment. A diagram illustrating an example of the functional configuration of the information processing system 1. A diagram illustrating an example of the hardware configuration of a server 10. A sequence chart illustrating an example of the operation of the information processing system 1. A diagram illustrating an example of the data configuration in a user database 112. A diagram illustrating an example of the data structure of a whole-body database 111. A diagram illustrating a UI database 113. A sequence chart illustrating an example of the operation of the information processing system 1 according to a modified example. A sequence chart illustrating an example of the operation of the information processing system 1 for using whole-body data in a user terminal 50.

[0013] 1. Configuration FIG. 1 is a diagram illustrating an overview of an information processing system 1 according to an embodiment. The information processing system 1 includes a whole-body scanner 40, a server 10, an application server 20, an application server 30, and a user terminal 50. The information processing system 1 is a system that manages and uses a user's whole-body data. The whole-body scanner 40 is a scanner device that acquires the user's whole-body data. The server 10 stores and manages the whole-body data. The application server 20 and the application server 30 provide services using the whole-body data, i.e., via the whole-body scanner 40. The application server 20 and the application server 30 are servers that are provided by different businesses and provide different services. When the application server 20 and the application server 30 are not distinguished from each other, they are collectively referred to as a "service platform." The user terminal 50 is a terminal device used by a user. The information processing system 1 is a system that uses whole-body data in different services, such as the application server 20 and the application server 30.

[0014] The whole-body data acquired by the whole-body scanner 40 is data obtained by measuring the user's entire body, and includes at least one of 3D modeling data and biometric data. The 3D modeling data is data representing a 3D model of the user. A 3D model is a digital representation of a three-dimensional object in a computer, such as a 3D avatar. The biometric data is data obtained by measuring the user's entire body, and includes information about the user's appearance, such as height and weight, as well as indicators of the living body's vital activities, such as heart rate, blood pressure, body temperature, respiratory rate, body fat percentage, and oxygen saturation.

[0015] The full-body scanner 40 includes, for example, a sensor group, a computer, and a housing (all not shown). The sensor group includes, for example, a camera and a distance sensor (or depth sensor). The computer processes image data and distance data obtained by the camera and distance sensor (i.e., obtained by photographing the user). This computer processing includes, for example, generating a 3D model from the data or communicating with a device that generates a 3D model from the data. The sensor group may further include sensors (such as a weight scale, height gauge, body surface thermometer, or body composition scale) that measure biometric data of the user. The housing forms a photography booth for photographing the subject, i.e., the user. The sensor group and the computer are fixed to the housing. The sensor group may include a measuring device for measuring biometric data. The computer may acquire the user's biometric data simultaneously with, before, or after photographing the user for generating the 3D model. The computer may also have an output device and an input device for providing a UI for providing information to the user in the photography booth and receiving instructions from the user. The output device includes, for example, a display and a speaker. Examples of input devices include a touch screen, a keypad, a keyboard, a camera, and a microphone.

[0016] The whole-body data obtained by the whole-body scanner 40 is stored in the server 10. The server 10 is operated by a business operator (hereinafter referred to as the "management business operator") whose purpose is to manage and provide whole-body data. In one example, the whole-body scanner 40 is also operated by this management business operator. The management business operator grants licenses to other businesses to use the whole-body data. The application server 20 and the application server 30 are each operated by a business operator separate from the management business operator. The business operator operating the application server 20 is referred to as the service business operator 21, and the business operator operating the application server 30 is referred to as the service business operator 31. The service business operator 21 and the service business operator 31 are different businesses and provide different types of services. For example, the service business operator 21 is an apparel business operator, and the application server 20 provides virtual fitting. The service business operator 31 is a fitness business operator, and the application server 30 provides fitness effect records.

[0017] All of these service providers receive a license to use whole-body data from the management provider. Since application server 20 and application server 30 provide different services, although they use the same whole-body data, the details of the data they actually use are different. For example, application server 20 uses 3D modeling data, while application server 30 uses biometric data, particularly weight and body fat percentage. Server 10 stores and manages many items of whole-body data, while providing each application server with only the data items used by that application server.

[0018] 2 is a diagram illustrating an example of the functional configuration of the information processing system 1. The information processing system 1 includes a storage unit 11, a receiving unit 12, an access unit 13, an access unit 14, an acquisition unit 15, an acquisition unit 16, a transmission unit 17, and a control unit 19. In this example, these functional elements are implemented in a server 10.

[0019] The storage unit 11 stores various data and programs. The data stored in the storage unit 11 includes a whole-body database 111, a user database 112, and a UI database 113. The whole-body database 111 is a database in which user identification information and whole-body data divided into multiple categories are recorded for each of multiple users (an example of a first database). The user database 112 is a database in which user information is recorded. The UI database 113 is a database in which service identification information, data categories to be used, and UI data for providing the service in the whole-body scanner 40 are recorded for each of multiple services (an example of a second database). These databases will be described in detail below.

[0020] The receiving means 12 receives an API request from the service platform, the API request including the user's user identification information and service identification information indicating the service. The accessing means 13 accesses the whole-body database 111. The accessing means 14 accesses the UI database 113. The acquiring means 15 acquires, via the accessing means 13, whole-body data of the user identified by the user identification information included in the API request, the whole-body data of a category identified by the whole-body database 111 as being used for the service identified by the service identification information included in the API request. The acquiring means 16 acquires, via the accessing means 14, UI data for displaying on the whole-body scanner 40 a menu for providing the service identified by the service identification information included in the API request. The sending means 17 sends an API response including the whole-body data acquired by the acquiring means 15 and the UI data acquired by the acquiring means 16 to the service platform. The controlling means 19 performs various calculations and controls.

[0021] 3 is a diagram illustrating an example of the hardware configuration of the server 10. The server 10 is a computer device having a CPU 101, a memory 102, a storage 103, and a communication IF 104. The CPU 101 is a processing device that performs various processes according to programs. The memory 102 is a main storage device that functions as a work area when the CPU 101 executes the programs. The storage 103 is a non-volatile auxiliary storage device that stores various data and programs. The communication IF 104 is a device that communicates with other information processing devices according to a predetermined communication standard (e.g., Ethernet (registered trademark)).

[0022] In this example, the programs stored in storage 103 include a program (hereinafter referred to as a "management server program") for causing the computer to function as server 10 in information processing system 1. When CPU 101 is executing the management server program, at least one of memory 102 and storage 103 is an example of storage means 11, communication IF 104 is an example of receiving means 12 and transmitting means 17, and CPU 101 is an example of access means 13, access means 14, acquisition means 15, acquisition means 16, and control means 19.

[0023] Although detailed description will be omitted, the application server 20 and the application server 30 are computer devices having the same hardware configuration as the server 10. Programs for enabling the computers to function as the application server 20 and the application server 30 in the information processing system 1 are installed on these computer devices, respectively.

[0024] The user terminal 50 is a computer device, such as a smartphone, tablet terminal, or PC, that has a CPU, memory, storage, communication IF, input device (e.g., at least one of a touch screen, keyboard, and microphone), and output device (e.g., at least one of a display and a speaker). The programs stored in this storage include a program (hereinafter referred to as a "client program") that causes a computer to function as the user terminal 50 in the information processing system 1.

[0025] 2. Operation 2-1. Control method of the whole-body scanner 40 Fig. 4 is a sequence chart illustrating the operation of the information processing system 1. Here, an example will be described in which user X of user terminal 50 uses a service (here, virtual fitting) provided by application server 20. Membership registration is required to receive the virtual fitting service provided by application server 20, and user X has already completed user registration.

[0026] To receive the virtual fitting service, User X launches a client program on the user terminal 50. Upon launch, the client program communicates with the application server 20 to perform user authentication. Once user authentication is complete, the client program displays a service menu. User X selects a desired item from the service menu. The user terminal 50 transmits a processing request RQ1 to the application server 20, requesting processing of the menu item selected by the user (step S101). The processing request RQ1 includes information identifying the menu item selected by the user. In this example, some time has passed since User X last scanned his or her entire body and generated a 3D model, and User X decides to scan his or her entire body again and generate a new 3D model. User X operates the user terminal 50 and selects the item "Update 3D model" from the menu of the client program. The client program transmits a processing request including information identifying the menu item "Update 3D model" to the application server 20.

[0027] Upon receiving the processing request RQ1 from the user terminal 50, the application server 20 performs processing according to the menu item indicated by the processing request RQ1 (step S102). In this example, "Update 3D model" is selected, which is a process that requires photography or measurement using the full-body scanner 40. For a process that requires photography or measurement using the full-body scanner 40, the application server 20 generates access information for accessing the application server 20 from the full-body scanner 40. The access information includes the URL of the application server 20, the user ID of user X, and the selected menu item. In one example, the access information is provided in the form of a two-dimensional code (e.g., a so-called QR code (registered trademark)). The application server 20 transmits a response including this access information to the user terminal 50 as a response to the processing request RQ1 (step S103).

[0028] Upon receiving the response from the application server 20, the user terminal 50 performs processing according to the received response (step S104). In this example, the user terminal 50 displays the access information, i.e., the two-dimensional code, included in the response. At this point, the user X is in the photography booth of the full-body scanner 40.

[0029] The full-body scanner 40 accepts the input of access information (step S104). In this example, the full-body scanner 40 uses a camera to read a two-dimensional code displayed on the user terminal 50. The full-body scanner 40 extracts a URL, user ID, and menu items from the read two-dimensional code. The full-body scanner 40 then sends a processing request RQ2 to the application server 20, requesting transmission of UI data for performing processing corresponding to the two-dimensional code (step S105). The UI data is data for providing a UI in the full-body scanner 40, and includes, for example, data for displaying a menu on the computer display of the full-body scanner 40 and data for outputting audio from the speaker. The destination of the processing request RQ2 is indicated by the URL extracted from the two-dimensional code. The processing request RQ2 includes identification information for the full-body scanner 40, as well as the user ID and menu items extracted from the two-dimensional code.

[0030] Upon receiving the processing request RQ2 from the whole-body scanner 40, the application server 20 prepares UI data corresponding to the menu item indicated by the processing request RQ2. In this example, the UI data is stored in the server 10. The application server 20 then transmits a processing request RQ3 to the server 10 requesting the provision of the UI data (step S106). In this example, the processing request RQ3 is an API request. The processing request RQ3 includes service identification information, a user ID, and a menu item.

[0031] The server 10 receives a processing request RQ3 from the application server 20. Upon receiving the request from the application server 20, the server 10 authenticates the received request (step S107). The authentication of the request includes, for example, authentication of the service platform and authentication of the user. The authentication of the service platform is authentication of the service provider, and in this example, authentication of whether the contract between the service provider 21 and the management provider is valid. The authentication of the service provider 21 uses, for example, the identification information of the service provider 21 and an authentication key of the service provider 21. The authentication of the user is authentication of whether user X is registered in the server 10.

[0032] Here, user authentication in the server 10 will be described. For example, user X has registered individually with each of the application servers 20 and 30, and each of the application servers 20 and 30 has assigned a unique user ID. As already explained, the server 10 provides full-body data to multiple application servers, including the application server 20 and the application server 30. To share the full-body data among these multiple application servers, the user ID must be reinterpreted. That is, the user ID included in a request received from the application server 20, such as the processing request RQ3, is the user ID provided by the application server 20. The server 10 refers to the user database 112 and reinterprets the user ID for the application server 20 as the user ID for the server 10. In the following explanation, expressions such as "referencing a database," "extracting information from a database," and "reading information from a database" will appear, and all of these expressions include a process in which a device accesses a database and obtains desired information.

[0033] FIG. 5 is a diagram illustrating an example of the data configuration in the user database 112. The user database 112 has multiple records. Each record corresponds to one user. Each record has main user attributes and secondary user attributes. The main user attributes are user attributes in the server 10, i.e., user attributes registered by the management provider. The main user attributes include at least one of the main user ID, name, gender, date of birth, address, and hobbies. The main user ID is the user ID in the server 10, i.e., the user ID given by the management provider. The secondary user attributes are user attributes in each application server. The secondary user attributes include service identification information (or service provider identification information) and a user ID in that service, i.e., a user ID given by each service provider.

[0034] The server 10 searches the user database 112 for a user ID for the same service as the user ID included in the processing request RQ3 (this is the user ID in the application server 20). If the same user ID is not found, the server 10 notifies the sender of the processing request RQ1 of an error. If the same user ID is found, the server 10 extracts from the user database 112 the main user ID corresponding to the found user ID (i.e., included in the same record). Once the main user ID is identified, user authentication is completed.

[0035] Referring again to Figure 4, once the service-based authentication and user authentication are completed, the server 10 extracts the requested data from the whole body database 111 and the UI database 113 (step S108).

[0036] FIG. 6 is a diagram illustrating an example of the data structure of the whole-body database 111. The whole-body database 111 has multiple records. Each record corresponds to one user. Each record has user identification information, classification identification information, partial data, and update identification information. The classification identification information is information that identifies the classification of the whole-body data. The classification of the whole-body data refers to the allocation of the whole-body data according to predetermined criteria. The classification may be hierarchical, such as major classifications, medium classifications, and minor classifications. Major classifications of the whole-body data include, for example, 3D modeling data and biological data. Medium classifications of the 3D modeling data include, for example, geometry, texture, and bone. Small classifications of geometry include, for example, vertices, edges, faces, and meshes. Medium classifications of the biological data include, for example, basic vital signs, extended vital signs, and activity data. Small classifications of the basic vital signs include, for example, body temperature, heart rate, respiratory rate, and blood pressure. Note that these classifications are merely examples.

[0037] Partial data is the main data of that category. For example, partial data of geometry is 3D modeling data that contains only geometry, i.e., does not include textures or bones. These data are given timestamps, i.e., time information. The timestamp indicates the time when each data was generated.

[0038] The update identification information is information that identifies the edition, or version, of the whole-body data. Even if the whole-body data is of the same user, the content of the data will differ depending on changes in body shape or physical condition. For example, if user X takes a photo and measures his / her body temperature and blood pressure for generating a 3D model on a certain day, the 3D modeling data, body temperature data, and blood pressure data generated on that day will be assigned a common update identification information. In this example, user X did not take any other measurements on that day, and the data for the other items corresponding to this update identification information is empty. Furthermore, if user X takes a photo and measures his / her heart rate and respiratory rate for generating a 3D model on a different day, the 3D modeling data, heart rate data, and respiratory rate and pressure data generated on that day will be assigned a common update identification information that is the next of the previous update information.

[0039] FIG. 7 is a diagram illustrating an example of the UI database 113. The UI database 113 has multiple records. Each record corresponds to one service. Each record includes service identification information, menu items, and a classification of whole-body data. In each record, multiple menu items correspond to one service identification information. Each menu item corresponds to one or more classifications. For example, in the top record, the service identification information "Company A Virtual Fitting" and the menu item "3D Model Update" are associated with the classifications "3D Model," "Height," and "Weight." When the processing request RQ3 includes the service identification information "Company A Virtual Fitting" and the menu item "3D Model Update," the server 10 extracts 3D modeling data, height data, and weight data from the whole-body database 111. Furthermore, the server 10 extracts UI data corresponding to the service identification information and menu items included in the processing request RQ3 from the UI database 113. This UI data is, for example, data for displaying a UI object using the whole-body data of the extracted classification. As an example, this UI data is data for displaying a screen including a display of the latest 3D model of user X. This completes the process of step S108.

[0040] Each piece of UI data recorded in the UI database 113 is prepared by, for example, each service provider. Each service provider registers the UI data that it has prepared in the UI database 113.

[0041] Referring again to Figure 4, after extracting the requested data, the server 10 generates a response using the extracted data (step S109). In this example, since the processing request RQ3 is an API request, the generated response RP3 is an API response. The processing request RQ3 includes the extracted classification's whole-body data and the extracted UI data.

[0042] The server 10 transmits the generated response (here, response RP3) to the application server 20, which is the sender of the processing request RQ3 (step S110). The application server 20 extracts UI data from the processing request RQ3. The application server 20 transmits a response RP2 including the extracted UI data to the whole-body scanner 40, which is the sender of the processing request RQ2 (step S111).

[0043] In step S112, the whole-body scanner 40 processes the received response RP2. Specifically, the whole-body scanner 40 displays a UI screen on the display in accordance with the UI data included in the response RP2. This UI screen guides user X to take a photo to update the 3D model, and includes, for example, a UI object displaying a 3D model of user X. The service menu provided by the application server 20 may be hierarchical. In this case, the whole-body scanner 40 may send a processing request to the application server 20 (and the application server 20 may send a processing request to the server 10) each time it crosses a hierarchy, and obtain new data from the application server 20. This allows the whole-body scanner 40 to perform scans for various applications (i.e., uses).

[0044] According to this example, the full-body scanner 40 can display a UI screen corresponding to the service that user X intends to use, and a UI screen using full-body data specific to user X. This UI screen is set individually for each application server (application server 20 and application server 30 in the above example) and provided by server 10. Therefore, the provider of the full-body scanner 40 does not need to prepare a UI corresponding to each service by itself. Each service provider can provide UI data that they have created themselves to the full-body scanner 40, and therefore can provide a UI with specifications that better meet the needs of end users.

[0045] The full-body scanner 40 uses the received UI data to scan the user X. This scan is intended to create or update 3D data. Depending on the application, the full-body scanner 40 may measure biometric data such as height and weight in addition to taking the image for generating the 3D data. The full-body scanner 40 transmits the data obtained by the measurements to the server 10. The data transmitted to the server 10 may be unprocessed raw data (i.e., the measurement data itself) or processed data (e.g., 3D modeling data). In addition to this data, the full-body scanner 40 transmits to the server 10 the user's identification information, the identification information of the service that performed the scan, and the identification information of the full-body scanner 40.

[0046] The server 10 writes the received data into the whole-body database 111. Although not described in Fig. 6, the whole-body database 111 may also record attribute information related to the scan, such as identification information of the service that performed the scan.

[0047] 8 is a sequence chart illustrating an example of a modified control method for the whole-body scanner 40. In this example, the processes up to step S108 are performed in the same manner as in FIG. 4, but steps S121 to S124 are performed instead of steps S109 and S110.

[0048] After extracting the requested data in step S108, the server 10 generates a response using the extracted data (step S121). Here, before generating a response to the application server 20, which is the sender of the processing request RQ3, data to be sent to the whole-body scanner 40 is generated. In this example, the processing request RQ3 includes identification information for the whole-body scanner 40, which is the sender of the processing request RQ2. The server 10 prepares the whole-body data and UI data extracted in step S108 as data to be sent to the whole-body scanner 40 identified by the identification information included in the processing request RQ3. The server 10 transmits the prepared data to the whole-body scanner 40 (step S122).

[0049] In step S121, the server 10 generates a response to be sent to the application server 20, which is the sender of the processing request RQ3. In this example, this response is a formal API response and does not include whole-body data or UI data. The server 10 sends the generated API response to the application server 20 as a response RP4 (step S123). Upon receiving the response RP4, the application server 20 sends a response RP5, which is a response corresponding to the processing request RQ2, to the whole-body scanner 40, which is the sender of the processing request RQ2 (step S124). In this example, this response is a formal response and does not include whole-body data or UI data.

[0050] In step S112, the whole-body scanner 40 processes the data received from the server 10. Specifically, the whole-body scanner 40 displays a UI screen on the display in accordance with the UI data included in the received data. This UI screen guides the user X to take a photo to update the 3D model, and includes, for example, a UI object that displays the 3D model of the user X.

[0051] 2-3. Use of Whole-Body Data in User Terminal 50 FIG. 9 is a sequence chart illustrating an example of the operation of the information processing system 1 for using whole-body data in the user terminal 50. In FIG.

[0052] In step S201, the user terminal 50 transmits a processing request to the application server 20. A client application is running on the user terminal 50, and the user X inputs an instruction to use whole-body data from the client application. In response to this instruction, the client application transmits a processing request (processing request RQ6) to the application server 20.

[0053] The processing request RQ6 includes information specifying the content or type of processing and information specifying the data used in the processing. The processing request RQ6 is, for example, an API request. The processing provided by the server 10 is predefined and publicly available, and service providers can implement desired processing from these processing into their applications. For example, the server 10 provides processing for displaying still images of 3D models, displaying videos of moving 3D models, editing 3D models, and displaying graphs of changes in biometric data. Identifying the data used in the processing includes, for example, identifying the 3D model to be displayed, and more specifically, identifying the user who is the subject of the 3D model, and, if the user has previously created multiple 3D models, identifying one of them.

[0054] Upon receiving the processing request RQ6 from the user terminal 50, the application server 20 performs processing in accordance with the processing request RQ6 (step S202). The application server 20 can perform multiple types of processing. For each of these multiple types of processing, it is defined whether the processing is to be performed by the application server 20 itself or by the server 10. This information is defined in the application server 20, for example, by a table or database. If the processing requested by the processing request RQ6 is to be performed by the server 10, the application server 20 generates a processing request for the server 10. This processing request includes information specifying the content or type of processing and information specifying the data to be used in the processing. The application server 20 transmits this processing request to the server 10 as a processing request RQ7 (step S203). The processing request RQ7 is, for example, an API request.

[0055] When receiving the processing request RQ7 from the application server 20, the server 10 authenticates the processing request RQ7 (step S204). The authentication of the processing request RQ7 is performed in the same manner as in step S107. When the processing request RQ7 is authenticated, the server 10 executes the processing instructed by the processing request RQ7 (step S205). This processing includes processing to extract or read at least a portion of the whole-body data from the whole-body database 111. The server 10 generates a response RP7 including data including the results of the processing. The response RP7 is, for example, an API response. The server 10 transmits the response RP7 to the application server 20, which is the sender of the processing request RQ7 (step S206). The processing result data in the response RP7 includes, for example, data for displaying a still image on the user terminal 50 or data for displaying a moving image on the user terminal 50. These data may have a general-purpose data format or a data format dedicated to the client application.

[0056] Upon receiving the response RP7 from the server 10, the application server 20 generates a response RP6 corresponding to the processing request RQ6. The response RP6 includes data on the results of the processing in the server 10. The application server 20 transmits the response RP6 to the user terminal 50, which is the sender of the processing request RQ6 (step S207).

[0057] Upon receiving the response RP6, the user terminal 50 processes the data included in the response RP6 (step S208). That is, the user terminal 50 can display a still image of the 3D model, a video of the 3D model moving, or a graph showing the progress of the biometric data.

[0058] 3. Modifications The present invention is not limited to the above-described embodiment, and various modifications are possible. Some modifications will be described below. Some of the following descriptions may be used in combination with at least some of the above-described embodiment or at least some of other modifications.

[0059] The device or system that sends an API request to the server 10 is not limited to a service infrastructure such as the application server 20 and the application server 30. For example, a device other than a server on the network, such as a full-body scanner 40 or a user terminal 50, may send an API request to the server 10.

[0060] The whole-body data is not limited to those exemplified in the embodiments. For example, the whole-body data may not include biological data and may be only 3D modeling data. Furthermore, the classification of the whole-body data does not depend on the example of the embodiment, and different classifications may be used. Classifications with different numbers of hierarchies may be used for the 3D modeling data and the biological data. Furthermore, some of the exemplified data classifications or items may be omitted.

[0061] Regarding the whole-body data, the scan attribute information recorded in the whole-body database 111 is not limited to that exemplified in the embodiment. The scan attribute information may include at least one of the following: identification information of the service that performed the scan; the menu item that performed the scan; the installation location of the whole-body scanner 40 (i.e., the location where the scan was performed); and the time when the scan was performed. The server 10 may narrow down the whole-body data using the scan attribute information in accordance with limiting information included in a request from another device, such as the application server 20, the whole-body scanner 40, or the user terminal 50. The limiting information is, for example, information for limiting the time or location where the scan was performed. The server 10 can provide the narrowed-down whole-body data to another device. The scan attribute information recorded in the whole-body database 111 can also be used as data for marketing, data for measuring royalties, or information for ensuring traceability.

[0062] When the server 10 receives a processing request from another device such as the application server 20, if the server 10 determines that there is missing data in the whole-body database 111 regarding the user whose whole-body data is requested to be processed, the server 10 may include information in the response to the other device prompting the other device to obtain the data.

[0063] The specific contents of the API request and the API response are not limited to those exemplified in the embodiment. For example, the full-body scanner 40 may have multiple types of sensors, and the API response sent from the server 10 may include information specifying the type of sensor to be used to scan user X from among these multiple types of sensors. A more specific example is as follows: The full-body scanner 40 has a camera and distance sensor, a body temperature sensor, a height gauge, and a weight scale. These are all examples of multiple types of sensors. The API response sent from the server 10 in response to a processing request to update the 3D model may include information specifying the sensor to be used to scan user X this time (e.g., information specifying the camera and distance sensor, the height gauge, and the weight scale). This means that when user X attempts to update his or her 3D model, the application also requests that his or her height and weight be measured (i.e., updated) as specifications.

[0064] The hardware configuration of the information processing system 1 is not limited to that exemplified in the embodiment. The information processing system 1 may have any hardware configuration as long as it can implement the required functions. For example, each database may be stored in an external device separate from the server 10, rather than in the storage device of the server 10.

[0065] Furthermore, the correspondence between the functional elements and the hardware elements is not limited to that exemplified in the embodiment, and the required functions may be implemented in any hardware.

[0066] The various programs executed by the CPU 101 and the like may be provided by downloading via a network such as the Internet, or may be provided in a state recorded on a computer-readable non-transitory recording medium such as a DVD-ROM. Note that each processor may be, for example, an MPU (Micro Processing Unit) instead of a CPU.

[0067] 1...information processing system, 10...server, 11...storage means, 12...receiving means, 13...access means, 14...access means, 15...acquisition means, 16...acquisition means, 17...transmission means, 19...control means, 20...application server, 21...service provider, 30...application server, 31...service provider, 40...full-body scanner, 50...user terminal, 101...CPU, 102...memory, 103...storage, 104...communication IF, 111...full-body database, 112...user database, 113...UI database

Claims

1. An information processing device having: a receiving means for receiving an API request from a service platform that provides a service to a user via a full-body scanner, the API request including the user identification information of the user and service identification information indicating the service; a first access means for accessing a first database in which user identification information and whole-body data divided into multiple categories are recorded for each of a plurality of users; a second access means for accessing a second database in which service identification information, a data category to be used, and UI data for providing the service on the full-body scanner are recorded for each of a plurality of services; a first acquisition means for acquiring, via the first access means, whole-body data of the user identified by the user identification information included in the API request, of a category indicated by the first database to be used for the service identified by the service identification information included in the API request; a second acquisition means for acquiring, via the second access means, UI data for displaying on the full-body scanner a menu for providing on the full-body scanner the service identified by the service identification information included in the API request; and a transmission means for transmitting to the service platform an API response including the whole-body data acquired by the first acquisition means and the UI data acquired by the second acquisition means.

2. The information processing device according to claim 1, wherein the whole-body scanner has a plurality of types of sensors, and the API response includes information specifying the sensor to be used for the scan performed on the user.

3. The information processing device described in claim 1, wherein the receiving means receives from the whole-body scanner scanner identification information that identifies the whole-body scanner, user identification information of the user, and measurement data measured by the whole-body scanner, and the first access means writes the whole-body data obtained from the measurement data into a record in the first database that corresponds to the user identification information.

4. An information processing device as described in claim 1, wherein in the first database, each whole-body data is recorded in association with a timestamp indicating the time at which the whole-body data was acquired, the API request includes limitation information that limits the time or place at which the whole-body data was acquired, and the first acquisition means acquires whole-body data corresponding to the limitation information from the first database.

5. An information processing method comprising the steps of: receiving an API request from a service platform that provides a service to a user via a full-body scanner, the API request including the user identification information of the user and service identification information indicating the service; accessing a first database in which, for each of a plurality of users, user identification information and whole-body data divided into a plurality of categories are recorded; accessing a second database in which, for each of a plurality of services, service identification information, data categories to be used, and UI data for providing the service in the full-body scanner are recorded; acquiring, via the first access means, whole-body data of the user identified by the user identification information included in the API request, of a category indicated by the first database to be used for the service identified by the service identification information included in the API request; acquiring, via the second access means, UI data for displaying on the full-body scanner a menu for providing, on the full-body scanner, the service identified by the service identification information included in the API request.

6. A program for causing a computer to execute the following steps: receiving an API request from a service platform that provides a service to a user via a full-body scanner, the API request including the user identification information of the user and service identification information indicating the service; accessing a first database in which, for each of a plurality of users, user identification information and whole-body data divided into a plurality of categories is recorded; accessing a second database in which, for each of a plurality of services, service identification information, data categories to be used, and UI data for providing the service on the full-body scanner is recorded; acquiring, via the first access means, whole-body data of the user indicated by the user identification information included in the API request, of a category indicated by the first database to be used for the service indicated by the service identification information included in the API request; acquiring, via the second access means, UI data for displaying on the full-body scanner a menu for providing, on the full-body scanner, the service indicated by the service identification information included in the API request; and transmitting an API response to the service platform, the whole-body data acquired by the first acquisition means and the UI data acquired by the second acquisition means.

Images