6.12 NEX: Data Stores

A data store uses the data storage features to manage and save large volumes of data over the network. This allows you to upload and download files of up to 10 MB. This also allows users to rate data uploaded by other users. See the CTR-NEX Library Function Reference for details.

6.12.1 Limits on Data Handled by Data Stores

Data handled by data stores must comply with the following limits.

  • No more than 100 data files must exist at a time per each single PrincipalID (including data files consisting solely of metadata).
  • Data files handled by storage server features must be no more than 10 MB in size per file.
  • The total size of all data files handled by storage server features must be no more than 10 MB (not including metabinaries) per each single PrincipalID.
  • The number of upload/download requests for data (not including metabinaries) handled by storage server features must be no more than 1000 requests per month per each single PrincipalID.
  • For data handled by storage server features, the sum total of amount of data uploaded plus amount of data downloaded (not including metabinaries) must be no more than 100 MB per month per each single PrincipalID.
  • No more than 100 KB of metabinary capacity existing at a time per each single PrincipalID.

Design your usage of the features with the above limits in mind, and describe your usage in the application forms on OMAS. Contact Nintendo at support@noa.com if you are planning a design that exceeds any of these restrictions.

No required guideline items.

6.12.2 Extent of Data Disclosure

When uploading data, you can configure access permission to allow access by just the owner (the PrincipalID which created the data), by users specified by the owner, by friends, or by everyone (completely open access).

If data uploaded to a data store is disclosed to other users, you must explain the extent of disclosure of said data, either in the manual or by displaying an explanation in the application before the data is disclosed. When data disclosure is not limited to just the owner, Nintendo also recommends displaying a message in the application (such as “Friends will also be able to view the uploaded data” or “Anyone will be able to view the uploaded data”) and obtaining user consent.

6.12.2.1 Informing Users of Extent of Data Disclosure

Guideline Item

An explanation of the extent of data disclosure must be given to the user, either in the manual or in the application before the data is disclosed.

Software to Be Tested

Applications that disclose data to other users via a data store.

Test Method
  1. Check the manual.
  2. Upload data.
Pass/Fail Determination

Passes if at least one of the following conditions is met.

  • Passes if in step 1, the manual includes text explaining the extent of disclosure of uploaded data.
  • Passes if in step 2, the application explains the extent of data disclosure before the user uploads data.

6.12.3 Data Collection via Data Stores

If the publisher collects only the minimum data necessary to provide a service, and uses it for no other purpose than to provide a service, it is not necessary to obtain user consent.

But if the publisher collects play histories or other data by uploading it to a data store, and uses it for other purposes such as statistics or analysis, the application must inform users of the content of the uploaded data and obtain their consent to sending the data.

Applications must not set up data stores for the purpose of exchanging highly confidential information, such as personal information. Therefore, it is prohibited to collect personal information (including NNIDs) using features that upload to a data store.

Additionally, if the application obtains consent and collects data either periodically or each time it connects to the network, you must implement a feature that allows the user to stop the sending of data. If the user has stopped the sending of data, then the application must get user consent again in order to start collecting data again.

These steps must be performed separately for each save data.

Note:

For background information on why applications are required to obtain consent and provide a way to opt out of sending data, see sections 6.14.4 User Consent Prior to Beginning Downloads and 6.14.5 Application Feature to Opt Out from Receiving Data in the BOSS chapter.

6.12.3.1 Prohibition of Collecting Personal Information on Data Stores

Guideline Item
Applications must not use data store upload features to collect personal information (including NNIDs).
Software to Be Tested
Applications that use data stores to collect data.
Test Method
Check the source code.
Pass/Fail Determination
Passes if no personal information or NNID is included in the collected data.

6.12.3.2 User Consent to Start Data Collection on Data Stores

Guideline Item

Applications that collect data using data stores must inform users of the types of data to be collected and obtain user consent before sending the data. Consent must be obtained separately for each set of save data.

Software to Be Tested
Applications that collect data using data stores and use it for some purpose other than purely providing a service (for example, for statistics or analysis).
Test Method
  1. Proceed to a scene where the application sends data.
  2. Check the source code to confirm that data is being sent only after user consent was obtained.
  3. Using a different save data, perform steps 1 through 2 again.
Pass/Fail Determination

Passes if all of the following conditions are met.

  • In step 1, the application displays a message informing the user of the content of the data that will be collected, and gets user consent to sending this data.
  • In step 2, the application only sends data after user consent has been obtained.
  • In step 3, the two conditions above are met.

6.12.3.3 Supporting a Feature to Stop Data Collection on Data Stores

Guideline Item

Applications that collect data either periodically or each time they connect to the network must implement a feature that allows the user to stop the sending of data.

Software to Be Tested

Applications that collect data using data stores, either periodically or each time they connect to the network, and use it for some purpose other than purely providing a service (for example, for statistics or analysis).

Test Method
  1. Check whether there is an opt-out feature within the application that allows the user to stop data collection.
  2. Use the opt-out feature to stop data collection, and then check the source code to confirm that data is no longer being sent.
  3. Check the source code to confirm that the opt-out feature is supported separately for each save data.
Pass/Fail Determination
Passes if all of the following conditions are met.
  • In step 1, the application implements a feature to stop data collection.
  • In step 2, data is not sent.
  • In step 3, the feature to stop data collection is supported separately for each save data.

6.12.3.4 Resuming Data Collection on Data Stores

Guideline Item
When resuming data collection after the sending of data was stopped, applications must again obtain user consent in accordance with section 6.12.3.2 User Consent to Start Data Collection on Data Stores. Consent must be obtained separately for each set of save data.
Software to Be Tested

Applications that collect data using data stores, either periodically or each time they connect to the network, and use it for some purpose other than purely providing a service (for example, for statistics or analysis).

Test Method
  1. Prepare two sets of save data (A and B) whose players have consented to sending data.
  2. Use the opt-out feature to stop data collection on save data A and B.
  3. On save data A, proceed to a scene where the application sends data for collection.
  4. On save data B, proceed to a scene where the application sends data for collection.
  5. Check the source code to confirm that data is being sent only after consent was obtained.
Pass/Fail Determination

Passes if all of the following conditions are met.

  • In step 3, the application again displays a message informing user A of the content of the data that will be collected, and gets user consent to sending this data.
  • In step 4, the application again displays a message informing user B of the content of the data that will be collected, and gets user consent to sending this data.
  • In step 5, the application only sends data after user consent has been obtained.

6.12.4 Support for Handling Multiple Save Data Files

Data is managed based on the owner’s PrincipalID, which creates the possibility that your application may not be able to distinguish between multiple save data files. Data uploaded from a save data file might be overwritten when the user uploads data later from a different save data file, so make sure to implement a means in your application to be able to identify the data itself. For example, you could add a SlotID attribute to the metadata for uploaded data and use this metadata to manage the data, thereby allowing for quick identification.

You must get user confirmation before deleting or overwriting data previously uploaded from a different save data file. Cases where deleting upload data does not adversely affect the game progress are exception to this rule. For instance, if only a limited number of data files can be saved and saving a new save data file requires that other data be deleted, display a message such as “You can only save up to XX data files. Delete data that came from another save data file, and create new data?" and get user confirmation before proceeding.

6.12.4.1 User Confirmation When Handling Multiple Save Data Files

Guideline Item

The application must get user confirmation before deleting or overwriting data previously uploaded from another save data file.

Software to Be Tested

Applications that allow deleting or overwriting data uploaded from other save data files.

Exceptions
When deleting upload data does not adversely affect the game progress.
Test Method
  1. Upload data.
  2. Fulfill the conditions needed to delete or overwrite data uploaded from another save data file.
Pass/Fail Determination

Passes if the application displays the following or an equivalent message and gains user confirmation before deleting or overwriting data: “You can only save up to XX data files. Delete data that came from another save data file, and create new data?”

6.12.5 Support for Using Different Cards

Starting up the same system with a different card inserted still allows the local user to access the same data store region, since the PrincipalID does not change. Consequently, your application must implement some means of preventing the user from accidentally deleting or overwriting data. One possible method is to add a NEX unique ID to the metadata of data files uploaded by your application. This will allow you to distinguish between data, based on the card the data is associated with.

No required guideline items.

6.12.6 Automatically Deleting Data

A valid period (expiration date) is set for all data uploaded to a data store except data that uses a permanent slot. The server checks periodically, and automatically deletes any data that has expired. Therefore, if the application attempts to access data that has been automatically deleted, Nintendo recommends taking care to ensure that failure to access that data does not result in any problems in the application.

No required guideline items.

6.12.7 Configuring Ratings

The rating feature allows users who have accessed uploaded data to rate the data. The library does make it possible to give negative ratings or for the same user to give multiple ratings to the same data file, but Nintendo recommends setting maximum and minimum allowed rating values in your application to prevent any extreme ratings from raising potential problems between users.
Example ratings:

  • Rate as “Good”
    Rates a data file as +1.
  •  Rate in three levels, as “Good,” “Fair,” or “Not Good”
    “Good” rates a data file as +1, “Fair” rates a file as ±0, and “Not Good” rates a file as -1.
  • Rate using stars (up to 10)
    A rating of ☆☆☆☆☆☆★★★★ would equate to a rating of +6.

The design of your rating system will depend on your application. Take care in your implementation to prevent a user from repeatedly giving negative ratings to the same data file or from otherwise using ratings to harass other users.

No required guideline items.

6.12.8 Submitting Multiple Ratings

You can configure the ratings settings for data when the data is first uploaded to a data store. When doing so, you must set RATING_FLAG_MODIFIABLE in the option flags. If you do not set this value, it is possible to submit multiple ratings by calling the nn::nex::DataStoreClient::RateObject function. The term "multiple ratings" means the ability of the same user to post multiple ratings for the same data. In such cases the previous rating will not be overwritten, so it will be as though multiple users had rated the data.

Allowing multiple ratings can degrade the fairness of the ratings for a game by allowing multiple biased ratings to be posted by the same user. Consequently, if you allow multiple ratings, Nintendo recommends not allowing a user to rate the same data item more than once in a short period of time. CTR-NEX provides the following features to restrict rating the same content more than once in a short time.

  1. Limiting by interval:
    Configure an interval such that after rating a data file, the user must wait for that period of time before being able to rate the same data file again.
  2. Limiting by specified date:
    Configure a date until which the user cannot rate the same data file again. For example, you could configure your application to prevent rating the same data file again until the next Monday, or the first of each month.

No required guideline items.

 


CONFIDENTIAL