Information processing device, information processing method, and program

Abstract

This invention provides an improved information processing device for a system that shares data between a terminal device and a server device that use whole-body data such as 3D data. [Solution] The information processing device has a receiving means that receives an API request containing user identification information and service identification information from a service infrastructure that provides services to users via a whole-body scanner; an acquisition means 15 that acquires whole-body data of a classification indicated by the whole-body database to be used for the service included in the API request via an access means 13; an acquisition means 16 that acquires UI data for displaying a menu on the whole-body scanner for providing the service indicated by the service identification information included in the API request via an access means 14; and a transmission means that sends an API response to the service infrastructure that includes the whole-body data acquired by the acquisition means 15 and the UI data acquired by the acquisition means 16.

Description

Technical Field

[0005] ,

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

Background Art

[0002] A technology for using data managed by a server on a terminal is known. For example, Patent Document 1 discloses a technology for transmitting, to an information processing apparatus as a terminal, data for outputting a 3D model composed of specific elements among 3D modeling data managed by a server.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In a system for sharing data between a terminal device that uses whole-body data such as 3D data and a server device, a more improved technology is provided.

Means for Solving the Problems

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

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

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

[0008] In the first database, each whole-body data entry is associated with a timestamp indicating the time the whole-body data was acquired, and the API request may include limitation information that limits the time or place where 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 this disclosure provides an information processing method comprising: receiving an API request from a service infrastructure that provides services to a user via a full-body scanner, the API request including the user's user identification information and service identification information indicating the service; accessing a first database in which user identification information and full-body data divided into multiple classifications are recorded for each of a plurality of users; accessing a second database in which service identification information, data classification to be used, and UI data for providing the service on a full-body scanner are recorded for each of a plurality of services; acquiring, via the first access means, full-body data of a user indicated by the user identification information included in the API request, for a classification 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 a menu on the full-body scanner for providing the service indicated by the service identification information included in the API request; and transmitting an API response including the full-body data acquired by the first acquisition means and the UI data acquired by the second acquisition means to the service infrastructure.

[0010] A further aspect of this disclosure provides a program for a computer to perform the following steps: receiving an API request from a service infrastructure that provides services 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 user identification information and full-body data divided into multiple classifications are recorded for each of a plurality of users; accessing a second database in which service identification information, data classification to be used, and UI data for providing the service on a full-body scanner are recorded for each of a plurality of services; acquiring, via the first access means, full-body data of a user indicated by the user identification information included in the API request, for a classification 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 a menu on the full-body scanner for providing the service indicated by the service identification information included in the API request; and transmitting an API response in which the full-body data acquired by the first acquisition means and the UI data acquired by the second acquisition means to the service infrastructure. [Effects of the Invention]

[0011] According to the present invention, an improved technology is provided for 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. [Brief explanation of the drawing]

[0012] [Figure 1] A diagram showing an overview of an information processing system 1 according to one embodiment. [Figure 2] A diagram illustrating the functional configuration of information processing system 1. [Figure 3] A diagram illustrating the hardware configuration of Server 10. [Figure 4]A sequence chart illustrating the operation of information processing system 1. [Figure 5] A diagram illustrating the data structure in user database 112. [Figure 6] A diagram illustrating the data structure of the whole-body database 111. [Figure 7] A diagram illustrating UI database 113. [Figure 8] A sequence chart illustrating the operation of a modified version of information processing system 1. [Figure 9] A sequence chart illustrating the operation of the information processing system 1 for using whole-body data on a user terminal 50. [Modes for carrying out the invention]

[0013] 1. Structure Figure 1 is a diagram illustrating an overview of an information processing system 1 according to one embodiment. The information processing system 1 comprises 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 for managing and utilizing the 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 servers 20 and 30 provide services using the whole-body data, i.e., via the whole-body scanner 40. The application servers 20 and 30 are servers for providing different services, each provided by a different service provider. When the application servers 20 and 30 are not distinguished, they are collectively referred to as the "service infrastructure." The user terminal 50 is a terminal device used by the user. The information processing system 1 is a system for utilizing whole-body data in different services, such as the application servers 20 and 30.

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

[0015] The whole-body scanner 40 includes, for example, a sensor array, a computer, and a housing (none of which are shown). The sensor array 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 processing by the computer includes, for example, generating a 3D model from this data, or communicating with a device that generates a 3D model from this data. The sensor array may further include sensors for measuring the user's biometric data (such as a weighing scale, height meter, body surface thermometer, or body composition analyzer). The housing forms a shooting booth for photographing the subject, i.e., the user. The sensor array and the computer are fixed to the housing. The sensor array may include measuring devices for measuring biometric data. The computer may acquire the user's biometric data simultaneously with or before / after photographing the user for 3D model generation. The computer may also have output and input devices for providing a UI to provide information to the user in the shooting booth and to receive instructions from the user. The output devices include, for example, a display and a speaker. Input devices include, for example, touchscreens, keypads, keyboards, cameras, and microphones.

[0016] The whole-body data obtained by the whole-body scanner 40 is retained by the server 10. The server 10 is operated by an operator (hereinafter referred to as the "management operator") for the purpose of managing and providing the whole-body data. In one example, the whole-body scanner 40 is also operated by this management operator. The management operator permits other operators than itself to use the whole-body data. The application server 20 and the application server 30 are each operated by an operator different from the management operator. The operator operating the application server 20 is referred to as the service provider 21, and the operator operating the application server 30 is referred to as the service provider 31. The service provider 21 and the service provider 31 are different operators and provide different types of services. For example, the service provider 21 is a clothing operator, and the application server 20 provides virtual fitting. The service provider 31 is a fitness operator, and the application server 30 provides a record of the effects of fitness.

[0017] All of these service providers receive permission from the management operator to use the whole-body data. Since the application server 20 and the application server 30 provide different services respectively, although they are services that use the same whole-body data, the details of the data actually used are different. For example, the application server 20 uses 3D modeling data, and the application server 30 uses, in particular, body weight and body fat percentage among the biological data. While storing and managing data of many items as the whole-body data, the server 10 provides only the data of the items used by each application server to that application server.

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

[0019] The storage means 11 stores various types of data and programs. The data stored by the storage means 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 classifications 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 classification to be used, and UI data for providing the service on the whole-body scanner 40 are recorded for each of multiple services (an example of a second database). Details of these databases will be described later.

[0020] The receiving means 12 receives an API request from the service infrastructure that includes the user's user identification information and service identification information indicating the service. The access means 13 accesses the whole-body database 111. The access means 14 accesses the UI database 113. The acquisition means 15 acquires, via the access means 13, the whole-body data of the user indicated by the user identification information included in the API request, which is classified by the whole-body database 111 to be used for the service indicated by the service identification information included in the API request. The acquisition means 16 acquires, via the access means 14, UI data for displaying a menu on the whole-body scanner 40 to provide the service indicated by the service identification information included in the API request. The transmitting means 17 transmits the API response, which includes the whole-body data acquired by the acquisition means 15 and the UI data acquired by the acquisition means 16, to the service infrastructure. The control means 19 performs various calculations and controls.

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

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

[0023] While a detailed explanation will be omitted, application server 20 and application server 30 are computer devices with the same hardware configuration as server 10. Each of these computer devices has programs installed that allow it to function as application server 20 and application server 30 in the information processing system 1.

[0024] The user terminal 50 is a computer device having a CPU, memory, storage, a communication interface, an input device (for example, at least one of a touchscreen, keyboard, and microphone), and an output device (for example, at least one of a display and speaker), such as a smartphone, tablet, or PC. The program stored in this storage includes a program (hereinafter referred to as the "client program") that causes the computer to function as the user terminal 50 in the information processing system 1.

[0025] 2.Operation 2-1. Control method for the whole-body scanner 40 Figure 4 is a sequence chart illustrating the operation of the information processing system 1. Here, we describe an example where user X on user terminal 50 uses a service (in this case, virtual fitting) provided by application server 20. Membership registration is required to receive the virtual fitting service from application server 20, and user X has already registered.

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

[0027] When the application server 20 receives a processing request RQ1 from the user terminal 50, it performs processing according to the menu item indicated by the processing request RQ1 (step S102). In this example, "3D model update" is selected, which is a process that requires imaging or measurement by the full-body scanner 40. For processes that require imaging or measurement by the full-body scanner 40, the application server 20 generates access information for the full-body scanner 40 to access the application server 20. 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 (for example, a so-called QR code®). The application server 20 sends a response containing this access information to the user terminal 50 as a response to the processing request RQ1 (step S103).

[0028] Upon receiving a 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 included in the response, i.e., a 2D code. At this point, user X is inside the scanning booth of the full-body scanner 40.

[0029] The full-body scanner 40 accepts access information input (step S104). In this example, the full-body scanner 40 reads a 2D code displayed on the user terminal 50 using its camera. The full-body scanner 40 extracts a URL, user ID, and menu items from the read 2D code. The full-body scanner 40 sends a processing request RQ2 to the application server 20 requesting the transmission of UI data for processing according to this 2D code (step S105). 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 sound from the speaker. The destination of the processing request RQ2 is indicated by the URL extracted from the 2D code. The processing request RQ2 includes identification information of the full-body scanner 40, as well as the user ID and menu items extracted from the 2D code.

[0030] Upon receiving a processing request RQ2 from the full-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 sends 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] Server 10 receives a processing request RQ3 from application server 20. Upon receiving a request from the application server, server 10 authenticates the received request (step S107). Request authentication includes, for example, service infrastructure authentication and user authentication. Service infrastructure authentication is the authentication of the service provider, and in this example, it is the authentication of whether the contract between service provider 21 and the management provider is valid. For the authentication of service provider 21, for example, the identification information of service provider 21 and the authentication key of service provider 21 are used. User authentication is the authentication of whether user X is registered with server 10.

[0032] Here, we will explain user authentication on server 10. For example, user X has registered separately with application server 20 and application server 30, and is assigned a unique user ID at each application server. As already explained, server 10 provides full-body data to multiple application servers, including application server 20 and application server 30. In order to share full-body data among these multiple application servers, it is necessary to reinterpret the user ID. That is, the user ID included in requests received from application server 20, such as processing request RQ3, is the user ID assigned at application server 20. Server 10 refers to the user database 112 and reinterprets the user ID at application server 20 as the user ID at server 10. In the following explanation, expressions such as "refer to the database," "extract information from the database," or "read information from the database" will appear, and all of these include the process of the device accessing the database and obtaining the desired information.

[0033] Figure 5 illustrates the data structure in the user database 112. The user database 112 has multiple records. Each record corresponds to one user. Each record has primary user attributes and secondary user attributes. Primary user attributes are user attributes in server 10, i.e., user attributes registered by the management provider. Primary user attributes include primary user ID, name, gender, date of birth, address, and at least one of the following: hobbies. Primary user ID is the user ID in server 10, i.e., the user ID given by the management provider. Secondary user attributes are user attributes in each application server. Secondary user attributes include service identification information (or service provider identification information) and the user ID for that service, i.e., the user ID given by each service provider.

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

[0035] Refer to Figure 4 again. Once the authentication of the service infrastructure and the user are complete, the server 10 extracts the requested data from the full database 111 and the UI database 113 (step S108).

[0036] Figure 6 illustrates 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. Classification identification information is information that identifies the classification of the whole-body data. Classification of whole-body data refers to the distribution of whole-body data according to predetermined criteria. Classification may be hierarchical, such as major classification, medium classification, and minor classification. Major classifications of whole-body data include, for example, 3D modeling data and biological data. Medium classifications of 3D modeling data include, for example, geometry, texture, and bone. Minor classifications of geometry include vertices, edges, faces, and mesh. Medium classifications of biological data include, for example, basic vital signs, extended vital signs, and activity data. Minor classifications of 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 for that classification. For example, geometric partial data is the 3D modeling data consisting only of geometry, i.e., data that does not include textures or bones. These data are given a timestamp, or time information. The timestamp indicates the time when each data was created.

[0038] Update identification information identifies the version of the whole-body data. Even with the same user's whole-body data, the content of the data will differ depending on changes in body shape or physical condition. For example, if user X takes photos for 3D model generation and measures body temperature and blood pressure on a certain day, the 3D modeling data, body temperature data, and blood pressure data generated on that day will be given common update identification information. In this example, user X did not measure any other items on that day, so the data for other items corresponding to this update identification information is empty. Furthermore, if user X takes photos for 3D model generation and measures heart rate and respiratory rate on a later day, the 3D modeling data, heart rate data, and respiratory rate / pressure data generated on that day will be given common update identification information, which is the next update after the previous update information.

[0039] Figure 7 illustrates 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 classifications of full-body data. In each record, multiple menu items correspond to one service identification information. One or more classifications correspond to each menu item. For example, in the top record, the classifications "3D model," "height," and "weight" are associated with the service identification information "Company A Virtual Fitting" and the menu item "3D model update." When 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 full-body database 111. Furthermore, the server 10 extracts UI data from the UI database 113 that corresponds to the service identification information and menu items included in processing request RQ3. This UI data is, for example, data that displays a UI object using the extracted full-body data of the classifications. For example, this UI data is data that displays a screen including the latest 3D model of user X. This concludes the processing of step S108.

[0040] Each UI data entry recorded in the UI database 113 is prepared by, for example, each service provider. Each service provider registers the UI data they have prepared in the UI database 113.

[0041] Refer to Figure 4 again. Once the requested data has been extracted, 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 whole body data of the classification and the extracted UI data.

[0042] Server 10 receives the generated response (in this case, response RP3) in the processing request RQ. The application server 20, which is the source of the processing request RQ3, receives the data (step S110). The application server 20 extracts the UI data from the processing request RQ3. The application server 20 sends the response RP2 containing the extracted UI data to the whole-body scanner 40, which is the source 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 according to the UI data contained in the response RP2. This UI screen guides user X to take a scan for updating the 3D model and includes, for example, a UI object that displays user X's 3D model. The service menu provided by the application server 20 may be hierarchical, in which case the whole-body scanner 40 may send a processing request to the application server 20 each time it crosses a hierarchy (and the application server 20 sends a processing request to server 10) 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] In this example, the full-body scanner 40 can display a UI screen corresponding to the service that user X intends to use, and using full-body data specific to user X. This UI screen is configured individually for each application server (application server 20 and application server 30 in the above example) and provided by server 10. Therefore, the operator of the full-body scanner 40 does not need to prepare the UI for each service themselves. Each service provider can provide the full-body scanner 40 with UI data they have created themselves, thus enabling them to provide a UI with specifications that better meet the end-user's requirements.

[0045] The full-body scanner 40 uses the received UI data to scan user X. This scan is for creating or updating 3D data. Depending on the application, the full-body scanner 40 may also measure biometric data such as height and weight in conjunction with the imaging for 3D data generation. The full-body scanner 40 transmits the data obtained from 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 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 to the server 10.

[0046] Server 10 writes the received data to the whole-body database 111. Although not explained in Figure 6, attribute information related to the scan, such as the identification information of the service that performed the scan, may also be recorded in the whole-body database 111.

[0047] 2-2. Modified control method of the whole-body scanner 40 Figure 8 is a sequence chart illustrating the operation of a modified version of the information processing system 1. In this example, the processing up to step S108 is performed in the same way as in Figure 4, but the processing from steps S121 to S124 is performed instead of the processing in 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, data to be sent to the whole-body scanner 40 is generated first, before generating a response to the application server 20, which is the source of the processing request RQ3. In this example, the processing request RQ3 includes the identification information of the whole-body scanner 40, which is the source 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, which is indicated by the identification information contained in the processing request RQ3. The server 10 then sends the prepared data to the whole-body scanner 40 (step S122).

[0049] Furthermore, in step S121, server 10 generates a response to send to application server 20, which is the source of processing request RQ3. In this example, this response is a formal API response and does not include whole-body data or UI data. Server 10 sends the generated API response as response RP4 to application server 20 (step S123). Upon receiving response RP4, application server 20 sends response RP5, which is the response corresponding to processing request RQ2, to whole-body scanner 40, which is the source of 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 according to the UI data contained in the received data. This UI screen guides user X to take a picture for updating the 3D model and includes, for example, a UI object that displays user X's 3D model.

[0051] 2-3. Use of whole-body data in user terminal 50 Figure 9 is a sequence chart illustrating the operation of the information processing system 1 for using whole-body data on the user terminal 50.

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

[0053] A processing request (RQ6) includes information that identifies the content or type of processing, and information that identifies the data to be used for processing. A processing request (RQ6) is, for example, an API request. The processing provided by Server 10 is predefined and publicly available, and service providers can implement the desired processing from among these into their applications. For example, Server 10 provides processing for displaying still images of 3D models, displaying videos of 3D models in motion, editing 3D models, and displaying graphs of the changes in biometric data. Identifying the data to be used for processing includes, for example, identifying the 3D model to be displayed, more specifically identifying the user who is the subject of the 3D model, and identifying one of the 3D models that the user has generated so far.

[0054] When the application server 20 receives a processing request RQ6 from the user terminal 50, it performs processing according to the processing request RQ6 (step S202). The application server 20 can perform multiple types of processing. For each of these multiple processes, it is defined whether the application server 20 performs it itself or whether it is performed 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 processing request RQ6 is to be performed by the server 10, the application server 20 generates a processing request to the server 10. This processing request includes information that identifies the content or type of processing, and information that identifies the data to be used for processing. The application server 20 sends this processing request to the server 10 as processing request RQ7 (step S203). Processing request RQ7 is, for example, an API request.

[0055] When server 10 receives a processing request RQ7 from application server 20, server 10 authenticates the processing request RQ7 (step S204). Authentication of the processing request RQ7 is performed in the same manner as in step S107. Once the processing request RQ7 is authenticated, server 10 executes the processing instructed by the processing request RQ7 (step S205). This processing includes extracting or reading at least a portion of the whole-body data from the whole-body database 111. Server 10 generates a response RP7 containing data including the results of the processing. Response RP7 is, for example, an API response. Server 10 sends the response RP7 to application server 20, the source of the processing request RQ7 (step S206). The processing result data in response RP7 includes, for example, data for displaying a still image on user terminal 50, or data for displaying a video on user terminal 50. This data may have a general-purpose data format or a data format specific to the client application.

[0056] Upon receiving response RP7 from server 10, application server 20 generates response RP6 corresponding to processing request RQ6. Response RP6 contains data showing the result of processing at server 10. Application server 20 sends response RP6 to user terminal 50, the source of processing request RQ6 (step S207).

[0057] Upon receiving response RP6, the user terminal 50 processes the data contained in response RP6 (step S208). Specifically, the user terminal 50 can display still images of the 3D model, videos of the 3D model in motion, or graphs showing the changes in biometric data over time.

[0058] 3. Variant The present invention is not limited to the embodiments described above, and various modifications are possible. Several modifications are described below. Some of the matters described below may be used in combination with at least some of the embodiments described above or at least some of other modifications.

[0059] The device or system that sends an API request to server 10 is not limited to a service infrastructure such as application servers 20 and 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 server 10.

[0060] Whole-body data is not limited to those exemplified in the embodiments. For example, whole-body data may not include biological data and may consist only of 3D modeling data. Furthermore, the classification of whole-body data may differ from those exemplified in the embodiments, and different classifications may be used. Different classification levels may be used for 3D modeling data and biological data. In addition, some of the classifications or items of the data exemplified may be omitted.

[0061] With respect to whole-body data, the scan attribute information recorded in the whole-body database 111 is not limited to those exemplified in the embodiments. 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 triggered the scan, the location of the whole-body scanner 40 (i.e., the location where the scan was performed), and the time the scan was performed. The server 10 may refine the whole-body data using the scan attribute information according to the limiting information included in requests from other devices such as the application server 20, the whole-body scanner 40, or the user terminal 50. The limiting information may be, for example, information to limit the time or location where the scan was performed. The server 10 can then provide the thus refined whole-body data to other devices. Furthermore, the scan attribute information recorded in the whole-body database 111 can be used as marketing data, data for measuring loyalty, or information to ensure traceability.

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

[0063] The specific contents of API requests and API responses are not limited to those illustrated in the embodiments. For example, if the whole-body scanner 40 has multiple types of sensors, the API response sent from the server 10 may include information specifying which of these multiple types of sensors will be used for user X's scan. A more specific example is as follows: The whole-body scanner 40 has a camera and distance sensor, a body temperature sensor, a height meter, 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 which of these sensors will be used for user X's scan (for example, information specifying the camera and distance sensor, the height meter, and the weight scale). This means that when user X tries to update their 3D model, the application specifications also require the measurement (i.e., update) of height and weight.

[0064] The hardware configuration of the information processing system 1 is not limited to those illustrated in the embodiments. 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 server 10's storage device.

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

[0066] The various programs executed by CPU 101, etc., may be provided via download over a network such as the Internet, or they may be provided recorded on a computer-readable non-temporary recording medium such as a DVD-ROM. Note that each processor may be replaced by, for example, an MPU (Micro Processing Unit) instead of a CPU. [Explanation of Symbols]

[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... Whole-body scanner, 50... User terminal, 101... CPU, 102... Memory, 103... Storage, 104... Communication interface, 111... Whole-body database, 112... User database, 113... UI database

Claims

[Claim 1] A receiving means for receiving API requests from the service infrastructure, A transmission means for transmitting the API response to the service platform. An information processing device having

Images