4. Information Made Public
Display names, public profiles, work information, listed schedules, reviews, and similar information may be viewed on the internet, including outside the Service. Registered email addresses and authentication information are not displayed on public profiles. In principle, messages and booking details are handled only by the Members concerned and by Operator personnel who need the information for safety, inquiry response, or a similar purpose.
External URLs, application explanations, decision reasons, and internal notes submitted for Provider-authorization review are not made public and, in principle, are handled only by the applicant and authorized Operator personnel. A public profile may show only the types of authorization that are currently active.
We do not tell the reported Member that a report was made, disclose the content of the report or the reporting person to that Member, or make those matters public. We also do not notify a person that the person has been blocked, although that person will no longer be able to send a new message. Only the Member can view works the Member has saved or marked as interesting; they are not disclosed to other Members, including the Provider of the work.
A public map shows an approximate location to protect valuable equipment and Member safety. Do not disclose an exact storage or handover location; coordinate it individually with the necessary counterparty.
A public profile may show the current number of independently published works, the recorded start of publication, the latest media-check date, the fact that a rights attestation was made, and a period without a confirmed serious Catalog-policy violation, together with an as-of date, relevant period, and limitations. These are facts based on AIVU Hub records or technical checks; they do not guarantee ownership of an URSA camera, authorship, identity, skill, or transaction safety. We do not publish unresolved, dismissed, or inconclusive reports, report counts, reporters, internal reasons, raw URLs, fingerprints, or an aggregate score. If the precise first-publication time of an existing work is unavailable, we do not infer it and show only the publication record that can be confirmed as of a stated date.
5. Records of Reports and Blocks
When a Member submits a report to the Operator, we record the reporting account, the reported Member, the relevant message, thread, booking, or work, the category (nuisance, suspected consumer use, harassment, fraud, danger, rights infringement, or other), the detailed text, time received, response status, response time, Operator personnel who handled the report, and internal Operator notes.
The channel for reporting a work from the public catalog without logging in does not collect the reporting person’s account. In that case, we do not store the source IP address itself. We store only a hash calculated with an added secret value, to the extent necessary to deter repeated submissions and permit later review, and a request identifier used to prevent duplicate resubmission.
For a block, we record only the blocking Member, the blocked Member, and the time of the action; we do not collect a reason. Blocking stops both Members from sending new messages to each other. It is not used to change the status of an existing booking or to change whether transaction records can be viewed.
Report content is handled only by authorized Operator personnel. For a report concerning a message, we display only the message identified in the report and a limited range immediately before and after it; we do not read the entire thread. The Operator does not continuously monitor conversations between Members. Access to report details is itself retained as an audit record. A report alone does not automatically suspend an account or set a block.
We retain a report record for the period necessary to respond, check for recurrence, address an objection, maintain safety, and respond to disputes. If the reported work or message is deleted, the report record itself is retained and only the reference to the deleted item is removed. A block is retained until the Member removes it and is deleted when removed. If an account is closed, block records concerning that Member are deleted.
6. Device Linking with the Vision Pro App and Viewing Records
Connecting to the Service from the Vision Pro app or a similar application requires an approval procedure performed by the Member on the web. For this approval procedure, we record the device name reported by the device, the requested scope of authorization, a verification value for the approval code (but not the code itself), status, the times of creation, expiration, approval, and use, and the polling interval. The approval procedure expires 15 minutes after issue. After expiration, a record that does not contain the code itself may remain for investigation of improper approval requests.
For an approved device, we record the account, device name, device type, scope of authorization, a hash of the issued access token (but not the token itself), issue time, expiration time (180 days after issue), last-used time, and the time and reason for revocation. A Member may unlink a device at any time, and the token for an unlinked device immediately becomes unusable. We also revoke every linked device when the Member resets a password or closes the account.
For viewing a work, we keep one record per Member and work containing only the time the work was saved, the time it was last opened, the time interest was recorded, and the time that interest was acknowledged. We do not collect playback position, playback duration, second-by-second playback logs, or a list of viewing history. A device sends to the Service only the device name and type displayed during device linking, updates to the saved, viewed, and interest states described above, report content, block and unblock actions and an account-closure request when initiated by the Member in the application, and technical information generated with each communication. Wearing status, eye gaze, hand movements, and other sensor information on the device are not sent to or stored by the Service.
Saved, viewed, and interest states are deleted when the account is closed.
8. Publication History, Moderation, and Appeals
We record publication, withdrawal, hold, restore, and other work events and publication-gate changes with the work, actor, time, policy version, event source, reason code, and change history. If an existing work has no reliable first-publication time, we distinguish a record that publication was observed at migration time.
Automated URL, media, metadata, thumbnail, duplicate, or other checks may hold a work before or after publication. An automated hold does not establish rights infringement or a policy violation. We distinguish and record a later duplicate claim, media replacement, dangerous file, substantiated rights complaint, and other reasons, and inform the Member how to correct the issue or appeal.
For moderation and appeals, we record the target, intake route, outcome (including upheld, not upheld, or inconclusive), policy code, severity, decision time, responsible personnel, summary of grounds, interim hold or restore, notice to the Member, appeal status and materials, appeal outcome, and access audit. As a rule, only an evidence-reviewed upheld decision is used for a public disadvantage or Marketplace eligibility; an unresolved, dismissed, or inconclusive report is not used adversely merely because it was submitted or because of the number of reports.
Operator personnel review decisions, and an affected Member may appeal through the stated channel. We may be unable to disclose all information to protect third-party rights, safety, privacy, or investigative confidentiality.
9. External Services and Processing Outside Japan
The Service uses Cloudflare, Inc. and related services, including Workers, D1, networks, and logs, as infrastructure. User information may therefore be processed by Cloudflare or its subcontractors to the extent necessary to provide the Service, maintain safety, and respond to failures, and may be handled at facilities outside Japan. The Operator appropriately supervises contractors through contracts and available settings.
When a public map is displayed, the user’s browser sends the IP address, user agent, referrer, requested tile coordinates and zoom level, and similar information to the map tile delivery servers of the OpenStreetMap Foundation. The range of the map viewed may be inferred from the tile information. For the purpose, destination, and external-service policies, see External Transmission and Cookies (Japanese).
Emails to Members—including email verification, password reset, account-closure confirmation, and notifications concerning bookings, cancellations, messages, inquiries, Provider applications, and reports—are sent using the email-delivery service of Resend, Inc. The Operator provides Resend with the destination email address and the notification body. The notification body does not include message text, inquiry content, a cancellation reason, a review reason, or internal Operator notes; it includes only a link to the relevant screen in the Service. The sending domain is aivuhub.com, and the Service is configured to use the Tokyo (ap-northeast-1) region. The Operator treats this as outsourced delivery, rather than provision of user information to a third party, and will continue to verify supervision of the contractor and whether information is handled outside Japan.
Email-delivery records do not include the destination, subject, or body. We retain only the notification type, target identifier, recipient Member, and delivery result.
When a work in the public catalog is played, the Service does not relay the video data itself. It redirects the user to external storage designated by the Member providing the work (currently Dropbox, Inc. or Google Drive from Google LLC). After the redirect, the user’s browser or application connects directly to that storage, sending the IP address, user agent, requested data range, and similar information to the storage provider. These providers are not contractors of the Operator, and their respective policies govern the information sent to them. The Operator restricts playback destinations to pre-approved storage URLs but is not responsible for the storage service’s availability, sharing settings, or traffic. For the purpose, destination, and external-service policies, see External Transmission and Cookies (Japanese).
12. Retention Periods
We retain user information while an account remains active and for the period necessary for the purposes described above. After a request to withdraw or delete information, we complete processing required for unfinished transactions, safety checks, and identity verification, and then delete or anonymize the information within a reasonable period. Records required for a legal retention obligation, dispute response, fraud prevention, or preservation of rights are retained only for the period necessary for that purpose. Infrastructure backups and security logs are progressively deleted according to the provider’s retention cycle.
Consent and acknowledgement evidence, work-rights attestations, publication events, media claims, and confirmed moderation decisions are retained as append-only audit records so that updating a current value does not erase the past. A correction, later version, or appeal adds a correction, supersession, or appeal record instead of overwriting the original row.
When an account is closed or a work is deleted, we stop the public profile and new retrieval path and delete or anonymize an unnecessary raw storage URL and current value. We may retain minimum records of a first claim, publication event, rights attestation, upheld enforcement, and related appeal only for the period necessary for law, preservation of rights, safety, prevention of improper rejoining, or dispute response. We do not retain a not-upheld or inconclusive record beyond what is necessary for an appeal, audit, or repeated handling of the same claim, and do not use it for a public disadvantage.
A hash retained to prevent repeated rights infringement, improper rejoining, spam, rate-limit evasion, or circumvention of a safety measure is subject to appropriate access controls and is deleted or irreversibly anonymized when that purpose ends. Specific periods are set in an operational retention schedule according to the type of information, rights-infringement and safety risk, legal obligations, and the duration of an appeal or dispute.
A preferred locale is a notification-language setting that the individual may later change. By contrast, the presented locale at the time of consent, acknowledgement, or attestation is an audit fact showing the document actually presented at that time and is not rewritten when the preferred locale changes. When Japanese authoritative text and an English reference translation are presented, we record the authoritative version and digest, reference revision and digest, relationship between them, meaning of the action, and server time in one row for each consent or attestation.
Submitted URLs and application content used for a current authorization review are retained for the period necessary for review, requests for revision, objections, and prevention of improper duplicate applications. A reapplication or withdrawal by the applicant overwrites or deletes the previous submitted URLs and application text; decision reasons, the reviewer’s summary of the basis for the decision, and action history are retained as audit records. AIVU Hub does not copy the works or materials themselves from an external service.
A Member may close the account through Settings. Upon closure, we suspend the Member’s authorizations; delete or reset the public-profile text, career history, base location, external URLs, and attributes collected during business registration (business type, corporate, organization, or trade name, business-use category, and representation version and time); replace the display name with “Closed account”; and replace the email address with an anonymous value that cannot be reversed. We stop listings, make works private, erase external URLs and application text submitted for review, delete login information and login sessions, revoke every linked device, and delete block and viewing-state records.
We do not delete bookings, records confirming terms, threads, messages, reviews, reports, consent evidence, work-rights attestations, publication history, media claims, confirmed moderation decisions, or audit records concerning authorizations to the extent retention is necessary as described above. These records also belong to the counterparty’s transaction history; deleting them at one party’s request would deprive the other party of the history of that party’s own transaction, the terms confirmed, and evidence for a dispute. After closure, only an anonymized account remains in these records. We delete the account row itself only to clean up a registration procedure that failed partway through, not in the normal account-closure procedure. A deletion request made under applicable law is assessed individually in accordance with Section 14.