Information processing device, information processing method, and information processing program
The information processing system enables secure data sharing and verification through data cards, addressing the inefficiencies of existing systems by allowing users to manage and verify data across accounts, thereby improving user convenience and service efficiency.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-09-19
- Publication Date
- 2026-04-01
AI Technical Summary
Existing systems fail to efficiently share user data, such as personal identification and action verification, between different accounts and services, leading to inefficiencies and security concerns.
An information processing system that includes a data card mechanism, allowing users to issue, manage, and verify data cards securely across accounts using a server device, enabling seamless data sharing and verification through a wallet application.
Facilitates secure and transparent data sharing between accounts, enhancing user convenience and service efficiency by allowing data cards to be easily verified and utilized across multiple services.
Smart Images

Figure 2026055836000001_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to an information processing apparatus, an information processing method, and an information processing program.
Background Art
[0002] There has been disclosed a technique that can reduce the burden of procedures at the government office window for both residents and staff, shorten the time at the window, and improve the overall efficiency (see Patent Document 1).
Prior Art Documents
Patent Documents
[0003]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0004] However, in the above prior art, useful data such as data for personal identification and data proving the user's actions cannot be provided to other users or other services.
[0005] The present application has been made in view of the above, and an object thereof is to share user data between accounts using a data card.
Means for Solving the Problems
[0006] The information processing apparatus according to the present application includes an issuance processing unit that provides a function of issuing a data card that enables data related to a user of a certain account to be used in other accounts to the account that becomes the issuer of the data card, a management unit that provides a function of managing a wallet for storing the issued data card to the user, and a verification processing unit that provides a function of verifying the data card to another account that is presented with the data card by the user and becomes the verifier of the data card. [Effects of the Invention]
[0007] According to one embodiment of the system, user data can be shared between accounts using data cards. [Brief explanation of the drawing]
[0008] [Figure 1] Figure 1 is an explanatory diagram showing an overview of the information processing system according to the embodiment. [Figure 2] Figure 2 is an explanatory diagram illustrating an example of creating data cards from useful data. [Figure 3] Figure 3 is an explanatory diagram illustrating how useful data can be easily and securely shared using data cards. [Figure 4] Figure 4 is an explanatory diagram illustrating how the product can be used. [Figure 5] Figure 5 is an explanatory diagram illustrating the concept of data selection. [Figure 6] Figure 6 is an explanatory diagram illustrating the concept of using data cards in bulk. [Figure 7] Figure 7 is an explanatory diagram illustrating the distribution of data cards. [Figure 8] Figure 8 is an explanatory diagram illustrating the formation of the data card utilization market. [Figure 9] Figure 9 is an explanatory diagram showing the template and the image of card creation. [Figure 10] Figure 10 shows an example of the configuration of a terminal device according to an embodiment. [Figure 11] Figure 11 shows an example of the configuration of a server device according to an embodiment. [Figure 12] Figure 12 is a flowchart showing the processing procedure according to the embodiment. [Figure 13] Figure 13 shows an example of a hardware configuration. [Modes for carrying out the invention]
[0009] The following describes in detail, with reference to the drawings, embodiments for implementing the information processing device, information processing method, and information processing program according to the present application (hereinafter referred to as "embodiments"). Note that these embodiments do not limit the information processing device, information processing method, and information processing program according to the present application. Furthermore, the same parts are denoted by the same reference numerals in the following embodiments, and redundant descriptions are omitted.
[0010] [1. Overview of the Information Processing System] First, with reference to Figure 1, an overview of the information processing system according to the embodiment will be described. Figure 1 is an explanatory diagram showing an overview of the information processing system according to the embodiment. As shown in Figure 1, the information processing system 1 according to the embodiment includes a terminal device 10 and a server device 100. The terminal device 10 and the server device 100 are connected to each other via a network N, either by wired or wireless means, enabling communication between them. This allows the terminal device 10 to cooperate with the server device 100. The network N is, for example, a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet.
[0011] Terminal device 10 is an information processing device used by user U. For example, terminal device 10 may be a smart device such as a smartphone or tablet, a PC (Personal Computer) such as a desktop or notebook (laptop), a mobile phone such as a feature phone, a PDA (Personal Digital Assistant), a game console or AV equipment with communication functions, an information appliance or digital appliance, a car navigation system, a wearable device such as a smartwatch, head-mounted display, or smart glasses. Alternatively, terminal device 10 may be a house or building compatible with the Internet of Things (IoT), a car, a home appliance, an electronic device, etc.
[0012] In this embodiment, the terminal device 10 is a smart device such as a smartphone or a tablet terminal used by the user U, and is a portable terminal device that can communicate with any server device via a wireless communication network such as LTE (Long Term Evolution), 4G (4th Generation), 5G (5th Generation: 5th Generation Mobile Communication System), Bluetooth (registered trademark), or wireless LAN. Further, the terminal device 10 has a screen such as a liquid crystal display, which has a function of a touch panel, and receives various operations on display data such as content, such as tap operations, slide operations, scroll operations, etc., from the user U by a finger or a stylus. Note that, among the operations on the screen, an operation performed on the area where the content is displayed may be regarded as an operation on the content. Further, the terminal device 10 may be not only a smart device but also an information processing device such as a desktop PC or a notebook PC.
[0013] The server device 100 is, for example, a computer such as a PC or a blade server, or a mainframe or a workstation. Note that the server device 100 may be realized by cloud computing.
[0014] In this embodiment, the server device 100 is an information processing device that cooperates with the terminal device 10 of each user U and provides the terminal device 10 of each user U with API (Application Programming Interface) services and various data for various applications (hereinafter referred to as apps), etc., and is realized by a computer, a cloud system, or the like.
[0015] Also, the server device 100 may be an information processing device that provides some online service to the terminal device 10 of each user U. For example, as an online service, the server device 100 may provide services such as Internet connection, search service, chat service, dialogue service by voice, image, video, etc., SNS (Social Networking Service), electronic commerce (EC: Electronic Commerce), electronic payment, online game, online banking, online trading, accommodation and ticket reservation, video and music distribution, news, map, route search, route guidance, route information, operation information, weather forecast, etc. In fact, the server device 100 may cooperate with various servers that provide the above online services to mediate the online service or be responsible for the processing of the online service.
[0016] In addition, the server device 100 can acquire user information regarding the user U. For example, as user information, the server device 100 acquires information (attribute information) regarding the attributes of the user U such as the gender, age, and residential area of the user U. Also, the server device 100 can acquire information regarding attributes such as the demographics (demographic attributes), psychographics (psychological attributes), geographics (geographical attributes), and behavioral (behavioral attributes) of the user U. Further, the server device 100 may acquire, as user information, the segment or persona (persona) to which the user U belongs in the field of marketing. Then, the server device 100 stores and manages information (attribute information) regarding the attributes of the user U together with the identification information (user ID, etc.) indicating the user U.
[0017] Furthermore, the server device 100 acquires various historical information (log data) indicating user U's actions from user U's terminal device 10, or from various servers based on the user ID, etc. For example, the server device 100 acquires location history, which is the history of user U's location and date and time, from the terminal device 10. The server device 100 also acquires search history, which is the history of search queries entered by user U, from the search server (search engine). The server device 100 also acquires browsing history, which is the history of content viewed by user U, from the content server. The server device 100 also acquires purchase history (payment history), which is the history of user U's product purchases and payment processing, from the e-commerce server or payment processing server. The server device 100 may also acquire listing history and sales history, which are the history of user U's listings on the marketplace, from the e-commerce server or payment processing server. The server device 100 also acquires posting history, which is the history of user U's posts, from posting servers that provide word-of-mouth posting services or SNS servers. The various servers mentioned above may also be the server device 100 itself. In other words, the server device 100 may function as the various servers mentioned above.
[0018] Furthermore, the number of devices included in the information processing system 1 shown in Figure 1 is not limited to those illustrated. For example, in Figure 1, only one terminal device 10 is shown for the sake of illustration, but this is merely an example and not limiting; there may be two or more.
[0019] Furthermore, the information processing system 1 according to this embodiment also includes an issuer device 200, which will issue the data cards described later, and a verifier device 300, which will verify the data cards. The issuer device 200 and the verifier device 300 may be general server devices, or they may be general terminal devices, just like the terminal device 10. Also, the server device 100 itself may become the issuer device 200 or the verifier device 300.
[0020] [2. Data Card] In this embodiment, in order to provide useful data such as user identity verification and activity verification exchanged between a user and a specific account in a messenger app or the like to other services, we will describe a method and mechanism for easily and securely providing or sharing useful data in card format between any accounts within (or via) an app, using the concept of a "data card".
[0021] Currently, messenger apps and similar services lack the functionality to provide data exchanged between users and specific accounts to other services. Therefore, useful user data exchanged between individual accounts (between individual accounts), between individual accounts and official accounts, between individual accounts and unofficial accounts, or between individual accounts and group accounts cannot be shared with other accounts.
[0022] Official accounts are accounts of businesses or other entities officially recognized by messenger apps or similar services, or that provide the messaging functionality for such services. Official accounts can communicate with users (including automated responses) and can provide various services in conjunction with web services, etc.
[0023] For example, even if you use your My Number Card to verify your identity on an official account of a local government (e.g., XX ward), you may still be asked to provide separate identification when using other accounts that require identity verification. Even if you spend time going through the process of using a local government's public personal authentication service, your data can only be used within that local government's services. Useful facts revealed as a result of using this service, such as "resident of that local government" or "correct combination of address and name," cannot be used as data in other accounts' services. This results in lost opportunities for both the user and the service provider.
[0024] Furthermore, unlike public services provided by local governments and other organizations, private services cannot utilize reliable information, making it difficult to determine whether the identification documents presented by users are genuine or fake (whether their contents are true or false). Even if the presented identification documents are genuine, there is a risk of misuse if they are borrowed or stolen. Additionally, users are often forced to reluctantly hand over their data without sufficient explanation regarding the effort involved in photographing their identification documents or where the data will be stored, resulting in disadvantages for both parties.
[0025] Furthermore, interactions and actions with one-on-one services, such as messaging apps, are generally not accessible to other businesses from a privacy protection standpoint. Therefore, even if a user verifies their identity using their My Number Card according to the prescribed procedure, they will need to perform the same verification again or by a different means if the account they are exchanging data with changes. This is very cumbersome for users, and businesses often have concerns about the risk of impersonation, data reliability verification, and storage methods.
[0026] Therefore, in this embodiment, a mechanism is introduced to easily and securely share useful data in card format (data card) between multiple services and accounts. For example, the other party in an exchange issues a certificate when a user performs an action (identity verification or a specified action). The certificate is created in a format that anyone can verify. The certificate is displayed in data card format, and the issuer, its content format, and validity conditions can be checked at any time. The data exchange platform supports the issuance, verification, presentation, and storage of data cards, ensuring the authenticity and transparency of the data cards.
[0027] Specifically, users select and save all data transmitted through the app, including interactions between users and businesses, as data cards. Furthermore, a function is provided to allow anyone to verify the accuracy of the content using encryption technology, supporting secure data distribution between app accounts. Note that "data card" is merely a convenient term; in practice, any data equivalent to the data cards in this embodiment will suffice.
[0028] For example, as shown in Figure 1, the server device 100 provides a data card creation function (data card issuance function) to the issuer (in this case, the issuer device 200) that has received a data card creation request (data card issuance request) from the user U's terminal device 10, and creates (issues) the data card in cooperation with the issuer (step S1). The issuer is a specific account that has exchanged data with the user. Note that the creation (issuance) of the data card itself may be performed independently (by the issuer alone), or it may be performed by the server device 100 as an internal process. For example, the server device 100 may create (issue) the data card on behalf of the issuer and send the data card to the issuer. Alternatively, the server device 100 itself may become the issuer. Furthermore, the server device 100 may provide the data card creation function (data card issuance function) within an application such as a messenger application on the user U's terminal device 10.
[0029] Next, the server device 100 provides the user U's terminal device 10 with a function to manage a wallet for storing data cards, and stores the data cards in the wallet in cooperation with the user U's terminal device 10 (step S2). In practice, the wallet may be generated within an application such as a messenger application on the user U's terminal device 10. Alternatively, the wallet itself may be an application.
[0030] The server device 100 receives an operation from user U's terminal device 10 regarding the data card stored in the wallet (step S3). In practice, user U may perform the operation on the data card stored in the wallet within the application on terminal device 10.
[0031] Next, when user U's terminal device 10 presents the data card stored in its wallet to the verifier, the server device 100 formats the data card data to suit the verifier's needs and presents it (step S4). In practice, user U may format the data card data stored in the wallet within the application on terminal device 10 and present it to the verifier.
[0032] Next, the server device 100 provides a data card verification function to the verifier (in this case, the verifier device 300) to whom the data card is presented, and verifies the data card in cooperation with the verifier (step S5). The verifier is another account to whom the user has presented the data card. Note that the verification of the data card itself may be performed independently (by the verifier alone), or it may be performed by the server device 100 as an internal process. For example, the server device 100 may perform the verification of the data card on behalf of the verifier and return the verification result to the verifier. Alternatively, the server device 100 may act as the verifier itself. Furthermore, the server device 100 may provide the data card verification function within an application such as a messenger application on the user U's terminal device 10.
[0033] Here, each of the processes S1 to S5 of the server device 100 may be executed on a different server device for each process, rather than on the same server device. In other words, the functions may be distributed across multiple server devices 100. Alternatively, the processes may be executed on the terminal device 10 or server device 100 of the user U, publisher, or verifier.
[0034] This ensures technical transparency in data flow, thereby promoting the use of the service with greater confidence.
[0035] The server device 100 may also use AI (Artificial Intelligence) such as GPT (Generative Pre-trained Transformer) to issue and verify data cards. For example, functions related to the issuance, verification, presentation, and storage of data cards may be implemented using AI such as GPT. GPT is a text generation AI and a language model capable of generating text using natural language processing.
[0036] [2-1. Entities] The user is the data subject. The issuer certifies the authenticity of the data and issues a data card. The verifier receives the data card from the user, verifies the reliability of the data using appropriate methods, and provides services based on the results. If the user inputs the data card into the AI, the AI becomes the verifier.
[0037] The platform provider provides all or part of the functions for the three parties (user, issuer, and verifier) to issue, verify, present, and store data cards. In other words, the platform provider provides a platform for issuing, verifying, presenting, and storing data cards. The platform provider itself may be any of the three parties. In this embodiment, the server device 100 functions as the platform provider.
[0038] [2-2. Issuance of Data Cards] Data cards are issued by the party with whom the user interacted or by a third party that verifies that interaction. For example, official accounts of local governments (e.g., XX ward) or platform providers may issue data cards. Platform providers may also create new data cards after verifying those issued by local governments.
[0039] In this embodiment, templates for content and UI (user interface) are generated, and the user selects (multiple) templates. The entity generating the templates can take the following forms:
[0040] Pattern 1: The issuer prepares a template in advance. Pattern 2: The user submits a template that they have formatted as they see fit (and the issuer approves it). Pattern 3: Share a template submitted by another user. Pattern 4: AI generates the necessary templates through natural language processing, etc.
[0041] Furthermore, users may create their own data cards and approve them as official data cards themselves. There may also be issuance options tailored to the recipient of the data card.
[0042] Furthermore, content approval, especially in Pattern 2, is impractical because it requires an application for each arbitrarily formatted template, making content verification extremely complex and resulting in numerous approval opportunities. Therefore, the issuer should determine the acceptable data range (e.g., address should be limited to city / ward level) and data type to reduce the number of content verification items and approval opportunities. The UI can also be customized by the user.
[0043] As shown in Figure 1, a data card DC includes the card issuer IS, the provided data PD, and the data card's trust mark MK. The card issuer IS is not limited to local governments or businesses; it may also be an individual. The provided data PD is automatically entered into other accounts. Alternatively, the entire data card DC can be sent to other accounts. The data card's trust mark MK indicates that the data has not been tampered with and that it has not expired. The platform provider may also verify the validity of the data before sending the provided data PD or data card DC, or the platform provider may provide and support means for the recipient (verifier) to verify the authenticity of the data.
[0044] Furthermore, as shown in Figure 2, data that is likely to be useful to the user is created into data cards from account interactions and reservation data. How the data is used will differ for each user. Figure 2 is an explanatory diagram showing an example of creating data cards from useful data.
[0045] For example, a message from the official account of a restaurant or other establishment could display a button that says "Convert order to data card." When this button is pressed, the order data is converted into a data card. In this case, the establishment would be the issuer.
[0046] In the example shown in Figure 2, a store order is used as a data card. The data related to the order is: "Order details: Chef's special pasta," "Calories: 567kcal," "Notes: Large portion, no mushrooms," and "Order date and time: 2024 / 6 / 27." For example, regarding the data "Calories: 567kcal," if the user is receiving meal management at a personal gym, this data can be used for purposes such as "I want to send a month's worth of data to my trainer" or "I want to have this data added to my healthcare app." Also, regarding the data "Notes: Large portion, no mushrooms," this data can be used for purposes such as "Next time, a regular portion will be fine..." or "I want to share that I ate this menu with everyone on social media."
[0047] As shown in Figure 3, useful data can be easily and securely shared between multiple services and accounts using data cards. Figure 3 is an explanatory diagram illustrating how useful data can be easily and securely shared using data cards.
[0048] For example, a user creates a data card when performing procedures such as obtaining a copy of their resident registration, obtaining a seal registration certificate, or claiming a refund for childcare fees in the local government "○○ Ward, Tokyo". For example, the user requests (demands) the issuance of a data card from the local government "○○ Ward, Tokyo". The issuer of this data card is the local government "○○ Ward, Tokyo".
[0049] Furthermore, as shown in Figure 2, a button labeled "Convert Order to Data Card" is displayed in messages from the official accounts of restaurants and other establishments. When this button is pressed, the order data is converted into a data card. The issuer of this data card is the establishment.
[0050] The wallet manages these data cards and, with the user's consent, shares them with other accounts. For example, when a user presents a data card to another account, that account can also view the data on that card. The wallet may be a standalone wallet app or a sub-app attached to a messenger app, etc.
[0051] [2-3. Saving Data Cards] In this embodiment, the server device 100 provides the user U's terminal device 10 with a function to manage a wallet for storing data cards as certificates in the user area. In practice, the server device 100 may provide a wallet management function (wallet management API) to the application on the user U's terminal device 10, and the application on the user U's terminal device 10 may use the wallet management function to create and manage a wallet. This adds wallet functionality to the user U's terminal device 10, allowing the user U to operate the wallet and data cards. The user area is preferably a secure element. Note that the storage location of the data cards does not have to be a specific wallet.
[0052] In this case, user U's terminal device 10 may store the raw data of the data card only in the wallet. Alternatively, user U's terminal device 10 may store the raw data in the wallet and also copy (replicate) the same content to the cloud as a backup. Note that user U's terminal device 10 stores encrypted data, not raw data, on the cloud. Furthermore, when user U's terminal device 10 stores encrypted data on the cloud, it may manage the data using blockchain with distributed ledger technology (DLT). In practice, the above processing may be executed by the server device 100 as internal processing of the application instead of by user U's terminal device 10.
[0053] Furthermore, users can manipulate data cards. For example, users can arbitrarily view, delete, issue, and format data cards. Users can also format existing data cards and issue new ones. In this case, the server device 100 will strongly verify the user's identity using FIDO authentication or other means as needed. In addition, to prevent data tampering, the limits and scope of data formatting that users can perform may be restricted by data formatting policies, etc. (e.g., changing XX Ward 1-1-1 to XX Ward).
[0054] Furthermore, as the number and capacity of data cards increase, it is anticipated that it will become difficult to store and manage them solely in the user area of user U's terminal device 10. In this case, the server device 100 may classify each user's data cards by user and manage them centrally. The wallet of user U's terminal device 10 may retrieve user U's data cards from the server device 100 when using them.
[0055] [2-4. Presenting your data card] Users can present data cards to any verifier. Users may present their data cards as they are, or they may format the data before presenting it. The wallet may, at the user's request or automatically, convert the contents of the data card to a two-dimensional code such as a QR code (registered trademark). In other words, users can present the contents of data cards stored in their wallet in the form of a two-dimensional code.
[0056] Examples of data formatting include partially hiding, partially blurring, and consolidating. For example, existing technologies such as selective disclosure are envisioned as a means of partially hiding data. As a means of partially blurring data, some data may be reduced (or simplified), such as changing "XX Ward 1-1-1" to "XX Ward." For numerical data, rounding may be performed. As a means of consolidation, a new data card C may be issued by the platform provider, such as "Data card A (issuer: XX Ward) + Data card B (restaurant) = Data card C (app)," and the data is consolidated. In this case, only data card C is presented, and the verifier trusts the platform provider in verifying data card C. Alternatively, the verifier can have the user separately present data card A and data card B from the reference information for verification. Or, the attributes disclosed may be (automatically) adjusted based on the level of relationship between users (accounts).
[0057] Examples of data presentation timing include the following patterns: For example, the platform provider recommends data presentation to users who match through attribute matching. Alternatively, users themselves present data cards about things they want to prove. For example, they could be posted on social media, such as OpenBadge. Or, data cards could be issued as needed (without using selective disclosure, etc.).
[0058] Furthermore, other accounts to which the data card is presented can also act as verifiers. In this case, the other accounts will use the verification function provided by the platform provider to verify the data card. In practice, however, other accounts may have their own verification functions and collect the necessary information (e.g., public keys) for verification before performing the verification.
[0059] [2-5. Data Card Verification] Data card verification assumes an asymmetric key digital signature and verifies the issuer's retention of confidential information using publicly available information. Verification is possible for anyone through the platform's verification function (any account can be a verifier). Especially in offline cases, visual verification may also be possible (e.g., checking if the clock is working). Furthermore, verifiers may have their own verification functions and collect the necessary information (e.g., public keys) for verification before performing the verification.
[0060] The verifier may request necessary data from the user in advance. The platform provider may perform data matching, but data cards will only be presented with the user's consent.
[0061] [2-6. Using Data Cards] Referring to Figure 4, let's explain, for example, how a user might use the service using data such as "resident of XX ward." Figure 4 is an explanatory diagram showing an image of how the service is used. For example, suppose a hotel's official account offers a discounted accommodation plan exclusively for residents of XX ward. The user selects a data card issued by XX ward from the data cards managed in the wallet, selects the address data indicating "resident of XX ward" from that data card, and formats it into the necessary data. For example, the user might remove their name and other personal information, and present a data card containing only the secure information "Tokyo, XX ward" to the hotel's official account. In this way, the wallet shares the data card that shows "resident of XX ward" with the hotel's official account.
[0062] The inn's official account verifies the presented data card using the platform provider's verification function to confirm that the user lives in XX Ward. At this time, the official account may confirm that the user's address is in "XX Ward" from the provided data PD, or it may confirm that the card issuer IS is in "XX Ward".
[0063] [2-7. Picking out necessary data] Refer to Figure 5 to explain how to store data cards and retrieve the necessary data. Figure 5 is an explanatory diagram illustrating the concept of data retrieval. As shown in Figure 5, data cards are stored in the wallet and can be created and provided at any time.
[0064] When a data card is presented, the wallet automatically selects the necessary data from the stored data cards and generates a data card for presentation. For example, the wallet can combine daily data such as "6 / 1 300kcal", "6 / 2 430kcal", "6 / 3 430kcal", etc., into a monthly data card called "June Calorie Intake Statistics Card," which can then be easily presented to a personal gym account or healthcare app.
[0065] Alternatively, the wallet could generate an "adult card" based on a data card containing "Name: XXX XXX," "Address: XX Ward, Tokyo," and "Age: 28," hiding unnecessary data for privacy protection and only proving that the user is an adult. This card could then be presented offline for age verification at places like bars.
[0066] The above wallet processing shall be performed by the terminal device 10 of user U using the wallet. However, in practice, the server device 100 may perform this as an internal process of the application.
[0067] [2-8. Batch use of data cards] Refer to Figure 6 to explain how to use multiple data cards at once in a store. Figure 6 is an explanatory diagram illustrating the concept of using multiple data cards at once.
[0068] For example, in a message sent to a user visiting a store, below the sentence, "We've created a data card tailored to this store! Please show us your 'Adult Card' before ordering alcohol," two buttons, "Show" and "Check Card," are displayed. When the "Show" button is pressed, the Adult Card becomes the item to be shown (shared) with the store. When the "Check Card" button is pressed, the contents of the Adult Card are displayed and can be checked.
[0069] Furthermore, in messages sent to users of the store, following the above content, the following sentence will be displayed below which are the words "Show your '○○ Ward Resident Card' and you can order the 'Special Sashimi Platter' for 500 yen less": "Show" and "Verify Card". When the "Show" button is pressed, the ○○ Ward Resident Card will be presented to (shared with) the store. When the "Verify Card" button is pressed, the contents of the ○○ Ward Resident Card will be displayed and can be verified.
[0070] [2-9. Use Cases] It's also possible to offer new services through accounts other than the official one of the local government, such as "○○ Ward, Tokyo." For example, a service offering discounted accommodations at a ryokan (traditional Japanese inn) in Izu exclusively to residents of ○○ Ward. In this case, the data presented as a data card only needs to include "Resident of ○○ Ward." Names and ages would be deleted or concealed to avoid disclosing them.
[0071] Furthermore, if you want to create a loan card using only your smartphone, you will need to provide data indicating either your "actual place of residence" or your "place of employment or study" as a data card. This data will be shared in an "easy" and "secure" manner.
[0072] Furthermore, the wallet automatically hides unnecessary data in response to user actions or according to predetermined rules. For example, the wallet automatically generates a data card indicating "Resident of XX Ward" from a data card indicating "XX Ward 1-1-1 XXX XXX (28)" in response to user actions.
[0073] Furthermore, the wallet automatically combines certain data with other data in response to user actions or according to predetermined rules. For example, the wallet automatically generates a data card indicating "Residing / Working in Tokyo" from a data card indicating "1-1-1 XXX XXX (28)" and a data card indicating "Employee of XXXX Corporation".
[0074] [2-10. Distribution of Data Cards] Refer to Figure 7 to explain the distribution of data cards. Figure 7 is an explanatory diagram illustrating the distribution of data cards. As shown in Figure 7, new data is distributed as data cards through the provision of the platform. At this time, the user selects the data card and the destination to which the data card will be presented.
[0075] For example, a request to create a data card for an order is sent to the official account of a restaurant or other store. In this case, the platform provider provides the store's official account with an API for creating and verifying the data card. The store's official account uses the creation and verification API to create a data card with the order data. The store's official account also registers the public key used to verify the data card, which was created in advance or easily created using SaaS, in a verification public key database. In other words, the data card becomes a public key certificate.
[0076] Furthermore, when using (presenting) a data card, the wallet requests the data card aggregation and privacy function utilization API from the platform provider. In other words, the wallet formats the data by calling the data card aggregation and privacy function utilization API. The wallet also works with the platform provider to back up the data card. The raw data of the data card is stored only within the wallet.
[0077] [2-11. Formation of the Data Card Utilization Market] Referring to Figure 8, we will explain the formation of the data card utilization market. Figure 8 is an explanatory diagram illustrating the image of the formation of the data card utilization market. For example, as shown in Figure 8, official accounts of companies, stores, etc., become data card issuers and issue data cards to users. In turn, users become data card subjects and use (provide data to) the official accounts of companies, stores, etc.
[0078] Official accounts of companies, stores, etc., that issue data cards pay an official account listing fee (and data card verification fee) to the server device 100, which acts as both a data card verifier and data card platform provider. The server device 100 provides the data card platform to the official accounts of companies, stores, etc., and verifies the data cards (provides the necessary functionality). The server device 100 also pays data card issuance affiliate commissions to card issuers who effectively utilize the service.
[0079] The user acting as the data card provider pays a data card purchase fee to the server device 100, which acts as both the data card verifier and data card platform provider, based on the number and type of data cards managed in the wallet (issued data cards). In practice, however, a wallet usage fee may be paid instead of a data card purchase fee.
[0080] Furthermore, the user requests a backup of their data card from the server device 100. The server device 100 stores the raw data of the data card only in the wallet and stores encrypted data on the cloud as a backup. The server device 100 also pays the user a data card usage reward corresponding to the data card used (presented).
[0081] [2-12. Template and Card Creation] Refer to Figure 9 to explain an example of templates and card creation. Figure 9 is an explanatory diagram illustrating the concept of templates and card creation. For example, as shown in Figure 9, the platform provider combines various data disclosure policies based on the template to support the creation of cards tailored to the recipient (friends, stores).
[0082] As shown in Figure 9, the level of abstraction of data cards decreases in the following order: profile template → publisher profile template → user profile template → friend data card / store data card. In other words, the profile template has the highest level of abstraction, while the friend data card / store data card has the lowest level of abstraction.
[0083] The profile template is a basic template provided by the platform. The profile template includes input fields for the user's name, address, and occupation (the area labeled "Provided Data PD" in Figure 1), as well as fields for the issuer logo (the area labeled "Issuer IS" on the card in Figure 1) and the verified mark (the area labeled "Trust Mark MK" in Figure 1). Note that there may be various variations of the profile template.
[0084] The issuer profile template may be provided by the issuer. The issuer profile template is a template that reflects the issuer's data disclosure policy and includes selected data items for the profile template. The issuer data disclosure policy may include, for example, being set by the issuer (which may be coordinated with the data request policy of the card distribution destination beforehand), requiring name and address, using a designated logo, requiring data verification (with a verification stamp), and allowing the use of any background image. However, the above is merely an example; in practice, it is not limited to the above example.
[0085] The user profile template is a template that reflects the user data disclosure policy and sets the data provision level compared to the publisher profile template. The user data disclosure policy could be set by the user (for example), disclosing the full address to close friends, or disclosing the address at the "ward" level to businesses. However, the above is just an example; in reality, it is not limited to the above example.
[0086] The issuer profile template and user profile template are intermediate templates. These templates include input fields for the user's name and address, as well as the issuer logo (e.g., "○○ Ward") and a "trust mark" as a verification mark. Reflecting the issuer data disclosure policy, the user's name and address are included, but the user's occupation is excluded as it is not required. Users may save the template at this level (issuer profile template or user profile template) in their wallet for reuse. Users can also store the "user profile template" in their wallet as a "draft" card for friend-facing data cards and store-facing data cards.
[0087] Friend-oriented and store-oriented data cards are personal data cards that reflect user data and preferences, and are issued based on a user profile template. User data and preferences include, for example, the data card image (UI-related, independent of data content) and stamps (example). However, the above is just an example. In reality, it is not limited to the above examples. Furthermore, friend-oriented and store-oriented data cards can be customized within the scope of the multiple policies mentioned above.
[0088] Here, the data card for friends reflects user data, including "Name: XXX XXX" and "Address: 7-1-1, XX Ward, Tokyo," as well as the "XX Ward" logo and a "trust mark." The data card for stores also reflects user data, including "Name: XXX XXX" and "Address: XX Ward, Tokyo," as well as the "XX Ward" logo and a "trust mark." Compared to the data card for friends, the data card for stores only displays the secure information of "XX Ward, Tokyo" from the address.
[0089] Specific use cases and templates for each level are described below.
[0090] (1) Service provision limited to residents of designated municipalities Use case pattern: Offer discounted accommodation plans exclusively to residents of XX ward. Publisher: ○○ Ward Verifier: Ryokan (Japanese inn) Platform: App Issuance: Create a data card using the template for the public personal authentication service of XX ward. Verification: Verification will be performed within the app's messenger function. Presentation: The data card will be presented with a portion of it blurred (e.g., XX Ward 1-1-1 → XX Ward).
[0091] (2) Changing the contents of data cards for each usage scenario Use case pattern: Modify the content depending on the relationship between the data card user and the verifier. Publisher: ○○ Ward Verifiers: Innkeepers and families Platform: App Issuance: Create a data card using the template for the public personal authentication service of XX ward. Verification: Verify within the app messenger. Presentation: The data card will be presented after partially concealing it (using existing technologies such as selective disclosure). For hotels, only the address will be concealed. For families, the name, gender, and address will be presented.
[0092] (3) Pre-creation of data cards for each usage scenario Use case pattern: Create multiple data cards in advance, corresponding to relationships that may require sending data cards. Publisher: ○○ Ward Verifiers: Innkeepers and families Platform: App Issuance: Create a data card from multiple templates provided by the public personal authentication service of XX ward. When creating the card, you can choose from three types of templates: one for family, one for friends, and one for strangers. Verification: Verify within the app messenger. Presentation: For inns, present information intended for strangers. For families, present information intended for families.
[0093] (4) Issuance of group cards Use case pattern: Create group cards (data cards for each group) for user groups that have a defined relationship, such as family or friends. Publisher: Stores and restaurants (e-commerce, etc.) Verifier: App Developer Platform provider: App developer (handles account management) Issuance: This assumes that a group organizer (the user acting as the organizer) will make a reservation for a group meal at a restaurant (with an official account). For example, the accounts (or uniquely identifiable identifiers) of the participating users (the users who will be participating) are registered in the app. When the group dines at the restaurant, the organizer issues a group card to commemorate the meal (by leaving a photo of the participants) as proof (they are asked to issue the card). At this time, the card is issued immediately by uploading the above photo using the issuer profile template for the restaurant. If the participating users have not yet added the official account as a friend, they add it as a friend, immediately download the issued group card, and save it to their app (wallet). Verification: Group users (users belonging to a group: the organizer or participants) will receive points by presenting the group card when they visit the restaurant. Alternatively, the group users can receive a discount by presenting the group card when they visit the restaurant again. Presentation: Present this card at the restaurant. Similar to individual cards (group cards for each user), this group card is linked to the restaurant's official account and can be combined with individual cards. For example, since a group card at a restaurant proves that a group dined together, this information can be used to incorporate the information "(We dined at the restaurant as a group) (visited)" into the individual card. In other words, group data cards and individual data cards can be combined (organized).
[0094] (5) Issuance of fitness club membership cards Use case pattern: Create a data card that can be used as a fitness club membership card. When the user presents the data card, information on higher-grade data cards will be suggested to the user based on the number of times the data card has been used. Publisher: Fitness Club Verifier: Fitness Club Platform: App Issuance: Fitness clubs issue "Membership Data Cards" to their members. Verification: Verification is conducted within the app messenger, where the fitness club checks the membership card within the app messenger to see "how often this member is using the service." Presentation: When you present your regular membership card in the app, it will suggest the next step in your data card based on your usage frequency. For example, it may include motivational messages such as, "You can get a Gold Membership Data Card after just 3 more uses."
[0095] (6) When using a student discount for movies (using an internship certificate card) Use case: Currently, the target data card itself does not exist, but temporary authentication is performed using another data card (a data card issued by another issuer), and the target data card will be submitted later. Example: A student tries to use a student discount at a movie theater but realizes they don't have their student ID data card. For example, this would be useful in a situation where they say, "Excuse me, I don't have my student ID data card, but I'll show you my internship certificate card on the app instead." The platform also suggests alternative data cards that could be used instead of the student ID data card. Publisher: The company where the internship took place. Verifier: Movie theater staff Platform: App Issuance: The company where the student is interning issues an internship certificate card to the student. Verification: The movie theater checks the internship certificate card within the app messenger to determine if the student is eligible for a student discount. The movie theater then asks the student to submit their student ID data card later (within a specified period). Later, once the student submits their official student ID data card and there are no issues, temporary use is officially approved.
[0096] [2-13. Effects of Data Cards] In this embodiment, by using a platform for issuing, verifying, presenting, and storing data cards, users can control their own data and distribute and reuse it for their own purposes. Furthermore, privacy protection is ensured. Customized data cards can be sent depending on the recipient. Verifiers can easily receive accurate data. Issuers do not have to repeatedly provide the same proof. In addition, platform engagement can be improved.
[0097] Furthermore, by using data cards as certificates, a certificate issuance system is realized that allows users to control their own actions on the service.
[0098] Furthermore, a cycle is created in which new data is generated from the service, such as "use the service" → "create a data card" → "accumulate data cards" → "organize data cards" → "use / show data cards" → "use the service"... (and so on).
[0099] Users can create data cards based on their favorite data, or they can have data cards automatically generated based on predetermined rules or by referencing data cards created by other users.
[0100] There are hundreds to thousands of data points. The wallet automatically selects the appropriate data card based on who it is presented to, and can be used once the user agrees (authorizes) it.
[0101] Data cards eliminate the hassle of data entry and verification, and provide a secure way to communicate that the data belongs to the other party. Because it contains reliable information, it can facilitate communication that maximizes LTV (Life Time Value).
[0102] [2-14. Additional Features] Set up different types of data cards and offer premium cards. For example, the more data cards you present, the stronger you become. Create a system that encourages you to present the card repeatedly, similar to a black card. You could also use the possession of a premium card to evaluate the user's trustworthiness.
[0103] Additionally, a function to change the design (image) of the data card displayed on the screen (i.e., to change its appearance) may be provided.
[0104] Furthermore, it would be possible to set a score for each card. For example, if the score represents the result of judging whether a user is a big eater through message exchanges, the user's eating ability score could be represented on a scale from "0" to "0.5" to "1", allowing for inconsistent judgments via data cards. The score could also be used for services, such as "special menu item for scores of 0.7 or higher."
[0105] Furthermore, when generating group cards for each designated user group, users within the group may endorse each other. Alternatively, the store may endorse the user group. For example, a couple of users (or the store giving an endorsement to the couple) could create a group card that serves as proof that "the two of us ate at XYZ Restaurant on [date]." The group card could also be used to collectively prove the presence of multiple users within the group.
[0106] [2-15. Other Perspectives] From another perspective, this embodiment realizes an automated user certificate creation system based on policies. For example, when the server device 100 receives user information entered by a user and receives approval from a predetermined approval authority, it registers that such user information has been approved, linking it to the user information. Next, when the server device 100 receives confirmation conditions (policies) from a requester requesting confirmation of user information, it determines whether or not user information matching the policy exists. Then, it provides information to the requester according to the determination result. Confirmation conditions (policies) include user information, approver information, and the approval authority.
[0107] [3. Example of terminal device configuration] Next, the configuration of the terminal device 10 will be described using Figure 10. Figure 10 is a diagram showing an example of the configuration of the terminal device 10 according to the embodiment. As shown in Figure 10, the terminal device 10 comprises a communication unit 11, a display unit 12, an input unit 13, a positioning unit 14, a sensor unit 20, a control unit 30 (controller), and a storage unit 40.
[0108] (Communications Section 11) The communication unit 11 is connected to the network N by wire or wireless connection and transmits and receives information to and from the server device 100 via the network N. For example, the communication unit 11 can be implemented using a NIC (Network Interface Card) or an antenna.
[0109] (Display section 12) The display unit 12 is a display device that displays various information such as location information. For example, the display unit 12 may be a liquid crystal display (LCD) or an organic electro-luminescent display (OLED). The display unit 12 may also be a touch panel display, but is not limited to this.
[0110] (Input section 13) The input unit 13 is an input device that receives various operations from the user U. For example, the input unit 13 has buttons for inputting characters, numbers, etc. The input unit 13 may also be an input / output port (I / O port) or a USB (Universal Serial Bus) port. If the display unit 12 is a touch panel display, a part of the display unit 12 functions as the input unit 13. The input unit 13 may also be a microphone that receives voice input from the user U. The microphone may be wireless.
[0111] (Positioning unit 14) The positioning unit 14 receives signals (radio waves) transmitted from GPS (Global Positioning System) satellites and, based on the received signals, acquires position information (e.g., latitude and longitude) indicating the current position of the terminal device 10. In other words, the positioning unit 14 determines the position of the terminal device 10. Note that GPS is just one example of a GNSS (Global Navigation Satellite System).
[0112] Furthermore, the positioning unit 14 can determine its position using various methods other than GPS. For example, the positioning unit 14 may use various communication functions of the terminal device 10 to determine its position as an auxiliary positioning means for position correction, etc., as described below.
[0113] (Wi-Fi positioning) For example, the positioning unit 14 determines the location of the terminal device 10 by utilizing the Wi-Fi® communication function of the terminal device 10 and the communication network provided by each telecommunications company. Specifically, the positioning unit 14 determines the location of the terminal device 10 by performing Wi-Fi communication, etc., and determining the distance to nearby base stations and access points.
[0114] (Beacon positioning) Furthermore, the positioning unit 14 may determine the location using the Bluetooth® function of the terminal device 10. For example, the positioning unit 14 determines the location of the terminal device 10 by connecting to a beacon transmitter connected via the Bluetooth® function.
[0115] (Geomagnetic positioning) Furthermore, the positioning unit 14 determines the position of the terminal device 10 based on the geomagnetic pattern of the structure, which has been measured in advance, and the geomagnetic sensor provided by the terminal device 10.
[0116] (RFID positioning) Furthermore, if, for example, the terminal device 10 is equipped with an RFID (Radio Frequency Identification) tag function equivalent to that of a contactless IC card used at a train station ticket gate or in a store, or if it is equipped with a function to read RFID tags, the location where it was used will be recorded along with the information on the payment or other transactions made by the terminal device 10. The positioning unit 14 may determine the location of the terminal device 10 by acquiring such information. Alternatively, the location may be determined by an optical sensor or infrared sensor equipped in the terminal device 10.
[0117] The positioning unit 14 may, if necessary, determine the position of the terminal device 10 using one or a combination of the positioning means described above.
[0118] (Sensor unit 20) The sensor unit 20 includes various sensors mounted on or connected to the terminal device 10. The connection can be wired or wireless. For example, the sensors may be detection devices other than the terminal device 10, such as wearable devices or wireless devices. In the example shown in Figure 10, the sensor unit 20 includes an acceleration sensor 21, a gyroscope sensor 22, a barometric pressure sensor 23, a temperature sensor 24, a sound sensor 25, a light sensor 26, a magnetic sensor 27, and an image sensor (camera) 28.
[0119] The sensors 21-28 described above are merely examples and not limiting. In other words, the sensor unit 20 may be configured to include some of the sensors 21-28, or it may include other sensors such as humidity sensors in addition to or instead of the sensors 21-28.
[0120] The acceleration sensor 21 is, for example, a 3-axis acceleration sensor and detects the physical movement of the terminal device 10, such as its direction of movement, velocity, and acceleration. The gyro sensor 22 detects the physical movement of the terminal device 10, such as its tilt in the three axes, based on its angular velocity. The barometric pressure sensor 23 detects the atmospheric pressure around the terminal device 10, for example.
[0121] Since the terminal device 10 is equipped with the acceleration sensor 21, gyroscope 22, barometric pressure sensor 23, etc., it becomes possible to determine the position of the terminal device 10 using technologies such as pedestrian dead-reckoning (PDR) that utilize these sensors 21 to 23. This makes it possible to obtain indoor location information that is difficult to obtain with positioning systems such as GPS.
[0122] For example, a pedometer using an accelerometer 21 can calculate the number of steps, walking speed, and distance walked. Additionally, a gyroscope 22 can be used to determine the user U's direction of movement, gaze direction, and body tilt. Furthermore, the barometric pressure detected by the barometric pressure sensor 23 can be used to determine the altitude and floor number of the user U's terminal device 10.
[0123] The temperature sensor 24 detects, for example, the ambient temperature around the terminal device 10. The sound sensor 25 detects, for example, the ambient sound around the terminal device 10. The light sensor 26 detects the ambient illumination around the terminal device 10. The magnetic sensor 27 detects, for example, the Earth's magnetic field around the terminal device 10. The image sensor 28 captures an image of the area around the terminal device 10.
[0124] The aforementioned pressure sensor 23, temperature sensor 24, sound sensor 25, light sensor 26, and image sensor 28 can detect the surrounding environment and conditions of the terminal device 10 by detecting atmospheric pressure, temperature, sound, and illuminance, respectively, and by capturing images of the surroundings. Furthermore, it becomes possible to improve the accuracy of the location information of the terminal device 10 based on the surrounding environment and conditions.
[0125] (Control Unit 30) The control unit 30 includes, for example, a microcomputer having a CPU (Central Processing Unit) or MPU (Micro Processing Unit), ROM (Read Only Memory), RAM (Random Access Memory), input / output ports, and various circuits. Alternatively, the control unit 30 may be composed of hardware such as an integrated circuit (ASIC) or FPGA (Field Programmable Gate Array). The control unit 30 includes a transmission unit 31, a reception unit 32, and a processing unit 33.
[0126] (Transmitter 31) The transmission unit 31 can transmit various information, such as information input by the user U using the input unit 13, various information detected by sensors 21-28 mounted on or connected to the terminal device 10, and location information of the terminal device 10 determined by the positioning unit 14, to the server device 100 via the communication unit 11.
[0127] (Receiving unit 32) The receiving unit 32 can receive various information provided by the server device 100, as well as requests for various information from the server device 100, via the communication unit 11.
[0128] (Processing 33) The processing unit 33 controls the entire terminal device 10, including the display unit 12. For example, the processing unit 33 can output and display various information transmitted by the transmission unit 31 and various information received from the server device 100 by the reception unit 32 to the display unit 12.
[0129] Furthermore, the processing unit 33 receives a data card from an issuer via the communication unit 11 (receiving unit 32) that has issued a data card that makes data about a user of a certain account available to other accounts, and stores it in the wallet.
[0130] Furthermore, the processing unit 33 receives operations from the user regarding the data card stored in the wallet via the input unit 13 and formats the data.
[0131] Furthermore, the processing unit 33, in response to the user's operation on the wallet, presents (transmits or displays) the data card to other accounts acting as data card verifiers via the communication unit 11 (transmitting unit 31) and presentation unit (output unit) such as the display unit 12.
[0132] (Storage unit 40) The storage unit 40 is implemented by, for example, semiconductor memory elements such as RAM (Random Access Memory) and flash memory, or by storage devices such as HDD (Hard Disk Drive), SSD (Solid State Drive), and optical discs. Various programs and various data are stored in this storage unit 40.
[0133] [4. Example of Server Device Configuration] Next, the configuration of the server device 100 according to the embodiment will be described using Figure 11. Figure 11 is a diagram showing an example of the configuration of the server device 100 according to the embodiment. As shown in Figure 11, the server device 100 includes a communication unit 110, a storage unit 120, and a control unit 130.
[0134] (Communications Department 110) The communication unit 110 is implemented, for example, by a NIC (Network Interface Card). The communication unit 110 is connected to the network N by wire or wireless connection.
[0135] (Storage unit 120) The storage unit 120 is implemented by, for example, semiconductor memory elements such as RAM (Random Access Memory) and flash memory, or by storage devices such as HDDs, SSDs, and optical discs. The storage unit 120 may store identification information (such as a user ID) indicating user U, as well as attribute information and history information (log data) of user U.
[0136] (Control unit 130) The control unit 130 is a controller, and is realized by executing various programs (corresponding to an example of an information processing program) stored in the internal storage device of the server device 100 using a storage area such as RAM as a working area, for example, by a CPU (Central Processing Unit), MPU (Micro Processing Unit), GPU (Graphics Processing Unit), ASIC (Application Specific Integrated Circuit), or FPGA (Field Programmable Gate Array). In the example shown in Figure 11, the control unit 130 has an acquisition unit 131, an issuance processing unit 132, a management unit 133, a presentation processing unit 134, and a verification processing unit 135.
[0137] (Acquisition part 131) The acquisition unit 131 acquires the search query entered by the user U. For example, when the user U enters a search query into a search engine or the like and performs a keyword search, the acquisition unit 131 acquires the search query via the communication unit 110. In other words, the acquisition unit 131 acquires the keyword entered by the user U into the search box of a search engine, website, or application via the communication unit 110.
[0138] Furthermore, the acquisition unit 131 acquires user information about user U via the communication unit 110. For example, the acquisition unit 131 acquires identification information (such as user ID), location information, and attribute information of user U from user U's terminal device 10. The acquisition unit 131 may also acquire identification information and attribute information of user U when user U is registered. The acquisition unit 131 then stores the user information in the storage unit 120.
[0139] Furthermore, the acquisition unit 131 acquires various historical information (log data) indicating the user U's actions via the communication unit 110. For example, the acquisition unit 131 acquires various historical information indicating the user U's actions from the user U's terminal device 10, or from various servers based on the user ID, etc. The acquisition unit 131 then stores the various historical information in the storage unit 120.
[0140] (Issuance Processing Unit 132) The issuance processing unit 132 provides the account that issues the data card, which makes data about a user of a particular account available to other accounts. For example, the issuance processing unit 132 provides the account with the function to issue a data card.
[0141] Furthermore, the issuance processing unit 132 provides a function to issue a data card that includes the issuer, data indicating the user's name and address, and a trust mark, when an account of a public institution such as a local government issues a data card.
[0142] Furthermore, the issuance processing unit 132 issues data cards using one of several templates corresponding to the level of abstraction of the data card.
[0143] Furthermore, the issuance processing unit 132 provides a function to issue data cards that serve as group cards, which are shared by multiple users belonging to the same group, to accounts of stores, including restaurants.
[0144] (Management Department 133) The management unit 133 provides users with the function to manage a wallet that stores issued data cards. The management unit 133 stores the raw data of the data card in the wallet. In addition, the management unit 133 also stores encrypted data of the data card in the cloud.
[0145] Furthermore, the management unit 133 receives requests from users to perform operations on data cards stored in the wallet, and in response to the user's actions, performs one of the following actions: viewing, deleting, issuing, or formatting the data card.
[0146] (Presentation processing unit 134) The presentation processing unit 134 formats and presents the data on the data card to suit the verifier when the user presents the data card stored in the wallet to the verifier. At this time, the presentation processing unit 134 provides a function of the wallet to format and present the data on the data card to suit the verifier.
[0147] For example, when formatting data, the presentation processing unit 134 may partially hide, partially blur, or combine data.
[0148] (Verification Processing Unit 135) The verification processing unit 135 receives a data card from a user and provides a function to verify the data card against another account that will act as the data card verifier.
[0149] Furthermore, the verification processing unit 135 provides a function to temporarily perform provisional authentication with a different data card than the one originally intended for other accounts acting as data card verifiers, and then verify the target data card later.
[0150] [5. Processing Procedure] Next, the processing procedure by the server device 100 according to the embodiment will be described using Figure 12. Figure 12 is a flowchart of the processing procedure according to the embodiment. Note that the processing procedure shown below is repeatedly executed by the control unit 130 of the server device 100.
[0151] For example, as shown in Figure 12, the issuance processing unit 132 of the server device 100 provides the account that becomes the issuer of the data card with a function to issue a data card that makes data about users of official app accounts of local governments, restaurants, etc., available to other accounts (step S101).
[0152] Next, the management unit 133 of the server device 100 provides the user's terminal device 10 with a function to manage the wallet that stores the issued data cards (step S102).
[0153] Next, the management unit 133 of the server device 100 receives an operation from the user regarding the data card stored in the wallet, and in response to the user's operation, performs one of the following actions: viewing, deleting, issuing, or formatting the data card (step S103).
[0154] Next, the presentation processing unit 134 of the server device 100 formats and presents the data on the data card to suit the verifier when the user presents the data card stored in the wallet to the verifier (step S104). For example, the presentation processing unit 134 hides, blurs, or combines some of the data on the data card.
[0155] Next, the verification processing unit 135 of the server device 100 receives a data card from the user and provides a function to verify the data card to another account that will act as the data card verifier (step S105).
[0156] [6. Variant Example] The terminal device 10 and server device 100 described above may be implemented in various other forms besides those of the embodiment described above. Therefore, the following describes modifications of the embodiment.
[0157] In the above embodiment, some or all of the processing performed by the server device 100 may actually be performed by the terminal device 10 (or an application running on the terminal device 10). For example, the processing may be completed in a standalone manner (by the terminal device 10 alone). In this case, the terminal device 10 is assumed to have the same functions as the server device 100 in the above embodiment. Furthermore, in the above embodiment, since the terminal device 10 is in cooperation with the server device 100, from the perspective of the user U, it appears as if the processing of the server device 100 is also being performed by the terminal device 10. In other words, from another perspective, it can be said that the terminal device 10 is equipped with the server device 100.
[0158] Furthermore, in the above embodiment, the server device 100 may prepare templates for each store or each type of business. For example, the user data required may differ between a restaurant and a fitness gym.
[0159] Furthermore, in the above embodiment, the official account of a local government may act as the issuer and issue a data card equivalent to a copy of a resident registration certificate or a seal registration certificate. Alternatively, the official account of the National Tax Agency may act as the issuer and issue a data card equivalent to a tax payment certificate.
[0160] Furthermore, in the above embodiment, an official account of a public institution such as a school, hospital, or transportation company may issue a data card. For example, an official school account may issue a data card equivalent to a student ID, certificate of enrollment, or academic transcript, or it may issue a data card that proves the role, position, or achievements in committee activities or club activities (club activities / circle activities). Also, an official hospital account may issue a data card equivalent to a medical card, or it may issue a data card that summarizes the medical information of patients or visitors, such as medical history and past medical history. Also, an official transportation company account may issue a data card equivalent to a reservation ticket or commuter pass. In this case, the server device 100 may, as a wallet function, restrict who the above data card may be presented to (presentation destination). For example, the server device 100 may only present the above data card when a request for presentation of the above data card is received from an official account of a public institution and the user consents to present it.
[0161] Furthermore, in the above embodiment, an official account of a company, organization, corporation, other business operator, or employer may act as the issuer and issue employee data cards. For example, a company's official account may issue a data card equivalent to an employee ID or certificate of employment, or it may create a data card that includes data on the employee's skills and achievements.
[0162] Furthermore, in the above embodiment, the official account of the certification body may issue a data card that can also be used as a certificate of qualification. Alternatively, the official account of the organization conducting the certification exam may issue a data card that certifies the pass / fail status or score of the certification exam.
[0163] Furthermore, in the above embodiment, the server device 100 may, as a wallet function, create a data card equivalent to a resume or work history by combining necessary data from the user's data cards. For example, the server device 100 may create a data card equivalent to a resume or work history by combining data cards issued by official accounts of schools, companies, etc., where the user was enrolled.
[0164] Furthermore, in the above embodiment, the official account of a travel agency or accommodation facility may act as the issuer and issue a data card containing data related to travel and accommodation reservations.
[0165] Furthermore, in the above embodiment, an official account of a financial institution such as a bank or securities company may issue a data card containing data on the user's financial assets. Alternatively, an official account of a real estate company or legal affairs bureau may issue a data card containing data on the user's real estate. Furthermore, an official account of a rental management company may issue a data card containing data on the user's monthly rent. In this case, the data on the data card includes information indicating the date of confirmation or issuance when the issuer verified the contents of the data.
[0166] Furthermore, in the above embodiment, the server device 100 may, as a wallet function, link with the issuer's official account and automatically update or reissue data cards periodically or whenever the content of the user's data changes.
[0167] Furthermore, in the above embodiment, the server device 100 may set an expiration date (or storage period) for the data cards stored in the wallet and automatically discard or destroy data cards that have expired. Alternatively, the issuer of the data card may set the expiration date for the data card.
[0168] Furthermore, in the above embodiment, data cards may be issued not only for the user's own data cards, but also for items owned by the user. For example, a data card may be issued that certifies that the seller of the user's owned items is a legitimately sold product. Alternatively, a data card (with a trust mark) may be issued that shows the results of authenticity determination or appraisal performed by a reliable institution.
[0169] [7. Effects] As described above, the information processing device (terminal device 10 and server device 100) according to the present application is characterized by comprising: an issuance processing unit 132 that provides an account that becomes the issuer of a data card with a function to issue a data card that makes data about a user of a certain account available to other accounts; a management unit 133 that provides a user with a function to manage a wallet that stores the issued data card; and a verification processing unit 135 that receives a data card from a user and provides a function to verify the data card to another account that becomes the verifier of the data card.
[0170] This allows user data to be shared across accounts using data cards.
[0171] Furthermore, the information processing device according to the present application further includes a presentation processing unit 134 that formats and presents the data on a data card to suit the verifier when the user presents the data card stored in the wallet to the verifier.
[0172] This allows the content of the data on the data cards presented to each verifier to be changed.
[0173] The presentation processing unit 134, when formatting the data, partially hides, partially blurs, or combines the data.
[0174] This allows for disclosing or concealing parts of the data on the data card to suit the verifier.
[0175] The management unit 133 receives operations from the user regarding data cards stored in the wallet, and, in response to the user's operation, performs one of the following actions: viewing, deleting, issuing, or formatting the data card.
[0176] This allows users to manipulate the data cards that have been issued to them.
[0177] Management unit 133 stores the raw data of the data card in the wallet.
[0178] This allows the raw data from the data card to be stored on the user's terminal device.
[0179] Management Unit 133 further stores the encrypted data from the data cards on the cloud.
[0180] This allows you to save backup data from your data card to the cloud.
[0181] The issuance processing unit 132 provides a function to issue a data card when an account of a public institution, such as a local government, is issued, which includes data indicating the issuer, the user's name and address, and a trust mark.
[0182] This allows for the issuance of data cards containing the user's name and address, guaranteed by a trusted institution.
[0183] The issuance processing unit 132 issues a data card using one of several templates corresponding to the level of abstraction of the data card.
[0184] This allows users to save templates at any stage for reuse, and then combine various data disclosure policies based on those templates to create cards tailored to specific recipients (friends, stores).
[0185] The issuance processing unit 132 provides a function to issue data cards that serve as group cards, which are shared by multiple users belonging to the same group, to accounts of stores, including restaurants.
[0186] This allows for the management of activity history on a group basis, and also enables groups to receive services on a group basis.
[0187] The verification processing unit 135 provides a function that allows other accounts acting as data card verifiers to temporarily perform provisional authentication with a different data card than the one originally intended, and then later verify the actual data card.
[0188] This allows you to temporarily use a different data card as a substitute if you don't have the necessary data card on hand.
[0189] From another perspective, the information processing device (terminal device 10) according to the present application is characterized by comprising a processing unit 33 that receives a data card from an issuer that has issued a data card that makes data about a user of a certain account available to other accounts, and stores the data card in a wallet, and a presentation unit (communication unit 11 or display unit 12) that presents the data card to other accounts that become verifiers of the data card in response to an operation on the user's wallet.
[0190] This allows data cards to be managed on the user's terminal device, and the data cards to be presented to the verifier through user operation.
[0191] The processing unit 33 receives an operation from the user regarding the data card stored in the wallet and formats the data.
[0192] This allows users to format the data on the data card as they wish.
[0193] Through any or a combination of the above-described processes, the information processing device according to the present invention can share user data between accounts using data cards.
[0194] [8. Hardware Configuration] Furthermore, the terminal device 10 and server device 100 according to the above-described embodiment are realized by a computer 1000 having a configuration such as that shown in Figure 13. The following explanation will use the server device 100 as an example. Figure 13 is a diagram showing an example of the hardware configuration. The computer 1000 is connected to an output device 1010 and an input device 1020, and has a configuration in which an arithmetic unit 1030, a primary storage device 1040, a secondary storage device 1050, an output interface 1060, an input interface 1070, and a network interface 1080 are connected by a bus 1090.
[0195] The arithmetic unit 1030 operates based on programs stored in the primary storage device 1040 and the secondary storage device 1050, as well as programs read from the input device 1020, and executes various processes. The arithmetic unit 1030 can be implemented using, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), an ASIC (Application Specific Integrated Circuit), or an FPGA (Field Programmable Gate Array).
[0196] The primary storage device 1040 is a memory device, such as RAM (Random Access Memory), that temporarily stores data used by the arithmetic unit 1030 for various calculations. The secondary storage device 1050 is a storage device where data used by the arithmetic unit 1030 for various calculations and various databases are registered, and can be implemented using ROM (Read Only Memory), HDD (Hard Disk Drive), SSD (Solid State Drive), flash memory, etc. The secondary storage device 1050 may be internal storage or external storage. The secondary storage device 1050 may also be a removable storage medium such as USB (Universal Serial Bus) memory or SD (Secure Digital) memory card. The secondary storage device 1050 may also be cloud storage (online storage), NAS (Network Attached Storage), file server, etc.
[0197] The output I / F 1060 is an interface for transmitting information to be output to output devices 1010, such as displays, projectors, and printers, and is implemented using connectors of standards such as USB (Universal Serial Bus), DVI (Digital Visual Interface), and HDMI (High Definition Multimedia Interface). The input I / F 1070 is an interface for receiving information from various input devices 1020, such as mice, keyboards, keypads, buttons, and scanners, and is implemented using, for example, USB.
[0198] Furthermore, the output interface 1060 and input interface 1070 may be wirelessly connected to the output device 1010 and input device 1020, respectively. In other words, the output device 1010 and input device 1020 may be wireless devices.
[0199] Furthermore, the output device 1010 and the input device 1020 may be integrated as a touch panel. In this case, the output I / F 1060 and the input I / F 1070 may also be integrated as an input / output I / F.
[0200] The input device 1020 may also be a device that reads information from, for example, an optical recording medium such as a CD (Compact Disc), DVD (Digital Versatile Disc), or PD (Phase Change Rewritable Disk), a magneto-optical recording medium such as an MO (Magneto-Optical disk), a tape medium, a magnetic recording medium, or a semiconductor memory.
[0201] The network interface 1080 receives data from other devices via network N and sends it to the computing unit 1030, and also transmits data generated by the computing unit 1030 to other devices via network N.
[0202] The arithmetic unit 1030 controls the output device 1010 and the input device 1020 via the output interface 1060 and the input interface 1070. For example, the arithmetic unit 1030 loads a program from the input device 1020 or the secondary storage device 1050 onto the primary storage device 1040 and executes the loaded program.
[0203] For example, when computer 1000 functions as a server device 100, the arithmetic unit 1030 of computer 1000 realizes the functions of the control unit 130 by executing a program loaded onto the primary storage device 1040. Alternatively, the arithmetic unit 1030 of computer 1000 may load a program obtained from another device via the network interface 1080 onto the primary storage device 1040 and execute the loaded program. Furthermore, the arithmetic unit 1030 of computer 1000 may cooperate with other devices via the network interface 1080 and call and use program functions, data, etc., from other programs on other devices.
[0204] [9. Other] Although embodiments of the present invention have been described above, the present invention is not limited by the content of these embodiments. Furthermore, the aforementioned components include those that can be easily conceived by those skilled in the art, those that are substantially the same, and those that fall within the so-called equivalent range. Moreover, the aforementioned components can be combined as appropriate. Furthermore, various omissions, substitutions, or modifications of the components can be made without departing from the gist of the embodiments described above.
[0205] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by known methods. In addition, the processing procedures, specific names, and information including various data and parameters shown in the above document and drawings can be arbitrarily changed unless otherwise specified. For example, the various information shown in each figure is not limited to the information shown.
[0206] Furthermore, the components of each illustrated device are functionally conceptual and do not necessarily need to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions.
[0207] For example, the server device 100 described above may be implemented using multiple server computers, and the configuration can be flexibly changed, such as by calling external platforms via APIs (Application Programming Interfaces) or network computing depending on the function.
[0208] Furthermore, the embodiments and modifications described above can be combined as appropriate, provided that the processing content is not inconsistent.
[0209] Furthermore, the terms "section, module, unit" mentioned above can be replaced with "means" or "circuit," etc. For example, the acquisition unit can be replaced with acquisition means or acquisition circuit. [Explanation of Symbols]
[0210] 1. Information Processing System 10 Terminal devices 100 Server Devices 110 Communications Department 120 Storage section 130 Control Unit 131 Acquisition Department 132 Issuance Processing Unit 133 Management Department 134 Presentation Processing Unit 135 Verification Processing Unit 200 Issuer device 300 Verifier Devices
Claims
1. An issuance processing unit provides the account that issues the data card, which allows data about a user of one account to be used by other accounts, to issue a data card. A management unit provides the user with a function to manage a wallet that stores the issued data card, The aforementioned user presents a data card, and a verification processing unit provides a function to verify the data card to another account that will act as the data card verifier. An information processing device characterized by comprising:
2. When the user presents the data card stored in the wallet to the verifier, the presentation processing unit formats and presents the data card data to suit the verifier. The information processing apparatus according to claim 1, further comprising:
3. The aforementioned presentation processing unit, when formatting the data, partially hides, partially blurs, or combines the data. The information processing apparatus according to feature 2.
4. The management unit receives an operation from the user regarding the data card stored in the wallet, and in response to the user's operation, performs one of the following actions: viewing, deleting, issuing, or formatting the data card. The information processing apparatus according to feature 1.
5. The management unit stores the raw data of the data card in the wallet. The information processing apparatus according to feature 1.
6. The aforementioned management unit further stores encrypted data from data cards on the cloud. The information processing apparatus according to feature 5.
7. The issuance processing unit provides a function to issue a data card when an account of a public institution, such as a local government, is issued, which includes the issuer, data indicating the user's name and address, and a trust mark. The information processing apparatus according to feature 1.
8. The issuance processing unit issues a data card using one of several templates corresponding to the level of abstraction of the data card. The information processing apparatus according to feature 1.
9. The aforementioned issuance processing unit provides a function to issue data cards that serve as group cards, which are shared by multiple users belonging to the same group, to accounts of stores, including restaurants. The information processing apparatus according to feature 1.
10. The verification processing unit provides a function to temporarily perform provisional authentication with a different data card than the one intended for verification to another account acting as a data card verifier, and then verify the intended data card later. The information processing apparatus according to feature 1.
11. A processing unit that receives a data card from an issuer that has issued a data card that makes data about a user of one account available to other accounts, and stores the said data card in a wallet, A presentation unit that presents the data card to another account that acts as a verifier of the data card based on the user's actions on the wallet. An information processing device characterized by comprising:
12. The processing unit receives an operation from the user regarding the data card stored in the wallet and performs data formatting. The information processing apparatus according to claim 11, characterized by comprising:
13. An information processing method performed by an information processing device, An issuance process that provides the account that issues the data card, which allows data about a user of one account to be used by other accounts, to issue a data card, and A management process that provides the user with a function to manage a wallet that stores the issued data card, The aforementioned user presents a data card, and a verification process is provided that allows another account acting as a data card verifier to verify the data card. An information processing method characterized by including
14. An information processing method performed by an information processing device, A process of receiving a data card from an issuer that has issued a data card that makes data about a user of one account available to other accounts, and storing the said data card in a wallet, A presentation step in which the user presents the data card to another account that acts as a verifier of the data card through an operation on the wallet; An information processing method characterized by including
15. A function to issue data cards that make user data from one account available to other accounts, and an issuance process procedure that provides this function to the account that issues the data cards. A management procedure that provides the user with a function to manage a wallet that stores the issued data card, A verification process procedure that, upon receiving a data card from the aforementioned user, provides a function to verify the data card to another account acting as the data card verifier. An information processing program characterized by causing a computer to execute it.
16. A procedure for receiving a data card from an issuer that has issued a data card that makes user data for one account available to other accounts, and storing the said data card in a wallet, A presentation procedure for presenting the data card to another account that acts as a verifier of the data card through an operation on the user's wallet, and An information processing program characterized by causing a computer to execute it.
Citation Information
Patent Citations
Counter support system and counter support program
JP2018139027A