WO2014073171A1 - 公開承認依頼方法、公開承認依頼システムおよび公開承認依頼サーバ - Google Patents

公開承認依頼方法、公開承認依頼システムおよび公開承認依頼サーバ Download PDF

Info

Publication number
WO2014073171A1
WO2014073171A1 PCT/JP2013/006241 JP2013006241W WO2014073171A1 WO 2014073171 A1 WO2014073171 A1 WO 2014073171A1 JP 2013006241 W JP2013006241 W JP 2013006241W WO 2014073171 A1 WO2014073171 A1 WO 2014073171A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
photo
public
server
approval request
Prior art date
Application number
PCT/JP2013/006241
Other languages
English (en)
French (fr)
Inventor
綾佳 一条
松崎　なつめ
布田　裕一
勇二 海上
松島　秀樹
ケネス アレクサンダー ニコルソン
Original Assignee
パナソニック株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック株式会社 filed Critical パナソニック株式会社
Publication of WO2014073171A1 publication Critical patent/WO2014073171A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/01—Social networking

Definitions

  • a publication approval request method is a publication approval request method executed in a server that publishes content, and the server specifies a first user to be included in the content.
  • a plurality of contact information including contact information in which agent information is associated with contact information of an authorized user who represents the agent user, and the server identifies the agent user;
  • the publishing user can publish the photo to the publishing user according to the approval status of the approval user without taking time and effort.
  • FIG. 1 is a configuration diagram of a public approval request system 10 according to the first embodiment.
  • FIG. 2 is a configuration diagram of the server 100 according to the first embodiment.
  • FIG. 3 is a configuration diagram of the mobile terminal 200 according to the first embodiment.
  • FIG. 4 is a configuration diagram of the mobile terminal 300 in the first embodiment.
  • FIG. 5 is a diagram showing an example of an approved user designation screen in the first embodiment.
  • FIG. 6A is a diagram showing an example of the structure of a photograph data set in the SNS photograph database according to the first embodiment.
  • FIG. 6B is a diagram showing an example of the structure of a photograph data set in the SNS photograph database according to the second embodiment.
  • FIG. 7 is a diagram showing transition of the public status and answer status in the photo data set according to the first embodiment.
  • FIG. 8 is a sequence diagram showing an operation at the time of publishing a photograph of the publication approval request system 10 according to the first embodiment.
  • FIG. 9 is a sequence diagram showing an operation at the time of publishing a photograph of the publication approval request system 10 according to the first embodiment.
  • FIG. 10 is a flowchart showing the operation of answer totaling processing by the server 100 in the first embodiment.
  • FIG. 11 is a sequence diagram illustrating an operation at the time of viewing a photograph of the public approval request system 10 according to the first embodiment.
  • FIG. 12 is a flowchart of the photo list generation process performed by the server 100 according to the first embodiment.
  • FIG. 13 is a configuration diagram of the public approval request system 10a according to the second embodiment.
  • FIG. 14 is a configuration diagram of the server 100a according to the second embodiment.
  • FIG. 42 is a flowchart illustrating an operation of subject detection processing by the server 100d according to the fifth embodiment.
  • FIG. 43 is a configuration diagram of the mobile terminal 400 in the first embodiment.
  • FIG. 44 is a diagram illustrating an example of a reply time limit setting screen displayed on the mobile terminal 200c of the publishing source user in the fifth embodiment.
  • FIG. 45A is a diagram showing an example of a data structure in the SNS user database in the first embodiment.
  • FIG. 45B is a diagram showing an example of a data structure in the SNS user database in the second embodiment.
  • FIG. 45C is a diagram showing an example of a data structure in the SNS user database in the modification of the fifth embodiment.
  • FIG. 45A is a diagram showing an example of a data structure in the SNS user database in the first embodiment.
  • FIG. 45B is a diagram showing an example of a data structure in the SNS user database in the second embodiment.
  • FIG. 45C is a diagram showing an example of a data structure in the
  • FIG. 45D is a diagram illustrating an example of a data structure in the SNS user database according to the modification of the fifth embodiment.
  • FIG. 46 is a diagram showing an example of a public approval request reception screen displayed on the approval user's mobile terminal 300 in the fifth embodiment.
  • FIG. 47A is a diagram showing a data structure example of a photograph list in the first embodiment.
  • FIG. 47B is a diagram showing a display example of a photo list displayed on the mobile terminal 400 of the disclosure destination user in the first exemplary embodiment.
  • FIG. 48 is a diagram showing a calendar display example of the reply deadline displayed on the mobile terminal of the approved user in the modification (9).
  • FIG. 49 is a diagram showing a screen display example in which a reply deadline displayed on the mobile terminal of the publishing source user is set with a calendar in the modified example (17).
  • the server When the server automatically requests public approval of the subject, the subject has contact means such as an email address or SNS ID, and the subject appropriately approves or rejects the disclosure. It must be able to be judged.
  • a public approval request method is a public approval request method executed in a server that publishes content, and the server is included in the content
  • the approved user may be the parent of the subject. That is, the approved user may be a proxy user for the subject.
  • an approval user such as an infant's parent
  • a contact means is requested to approve or reject a photograph of a proxy user (such as an infant). And it is possible to carry out appropriately.
  • the publishing source user can publish the photo to the publishing destination user according to the approval status of the approval user without taking time and effort.
  • the first agent information and the second agent information are a user ID, a feature amount of a face image, or the like.
  • the second agent information may be received from the terminal of the content publishing user.
  • the step of acquiring the second agent information includes a step of extracting a feature amount of a face image from the image as the second agent information when the content includes an image. May be.
  • the facial feature amount is compared, and the contact information of the proxy user included in the content is extracted from the plurality of contact information.
  • the contact information with the highest match level is extracted when the match level is equal to or higher than a certain threshold.
  • each of the plurality of contact information includes a feature amount of the face image of the proxy user as the first proxy information, and the plurality of contact information has a priority in advance.
  • the face extracted in the step of acquiring the second agent information in order from the contact information with the highest priority among the plurality of contact information may be extracted by comparing the feature amount of the image and the feature amount of the face image of the plurality of contact information.
  • a contact extraction unit that extracts a contact of an authorized user who represents the user to be delegated from the plurality of contact information, and a public approval request is transmitted to the terminal using the contact of the authorized user, Before from terminal An answer totaling unit that receives the response; and a public management unit that makes public and non-public determinations according to the response result, wherein the terminal generates an approval or rejection response for the public approval request.
  • a public approval request server is a public approval request server that publishes content, and is a first for specifying a proxy user included in the content.
  • a storage unit storing a plurality of contact information including contact information in which one agent information and contact information of an authorized user who represents the agent user are associated; and for specifying the agent user Contact information of an authorized user who obtains second agent information, compares the second agent information with the first agent information, and represents the agent user from the plurality of contact information
  • a contact extraction unit that extracts a response, a response approval unit that transmits a public approval request to the terminal using the contact information of the approved user, and receives the response from the terminal, and public and private according to the response result Make a judgment And an open management unit.
  • FIG. 1 is a diagram showing an overall configuration of a public approval request system 10 according to the present embodiment.
  • the public approval request system 10 includes a server 100 (public approval request server), a mobile terminal 200 of a public user, a mobile terminal 300 of an approved user, and a mobile terminal 400 of a public user.
  • the SNS user is a proxy user
  • at least the user name (user_name), the user ID (user_id), and the contact information of the proxy user (email_address2) are stored in the SNS user data.
  • the contact address (email_address1) of the SNS user may not be registered.
  • the SNS photo database 106 is a database for storing photo data sets.
  • FIG. 6A is a diagram showing an example of the structure of a photo data set in the SNS photo database 106.
  • the photo data set includes a user ID (sharer) of the publishing user, a photo ID (photo_id), a public status (public / private) (status), a response status (approval requested / all responded) (ans_status), approval Number (ok_no), number of rejections (ng_no), number of approved users (approver_no), user ID of approved user (approver (h is an integer of 1 or more)), viewable user list, and photo data (photo_data) Etc. are included. A unique number is assigned to each photo ID for each photo. The individual reply status (unanswered / answered) (res) is added to the user ID of the approved user.
  • the contact extraction unit 101 outputs the contact information of the approved user extracted from the SNS user database 105 and the user ID of the approved user to the answer counting unit 102.
  • the contact extraction unit 101 outputs the contact information of the approved user extracted from the SNS user database 105 to the public photo management unit 103.
  • the response counting unit 102 (1) transmits a public approval request for requesting approval for the publication of a photograph to the mobile terminal 300 of the approval user, and (2) sends a response to the public approval request from the mobile terminal 300. The answers received and aggregated are aggregated.
  • the response counting unit 102 counts the number of approvals and rejections. The counted number is recorded in the photo data set. Each time the answer counting unit 102 increments the number of approvals or the number of rejections, it compares the total number of approvals and the number of rejections with the number of approved users in the photo data set. When the total number of approvals and the number of rejections matches the number of approved users in the photo data set, the answer counting unit 102 considers that all the approved users have received answers. The answer totaling unit 102 totals the answers when all the answers are available, and outputs to the public photo management unit 103 that the answers are ready.
  • Public photo management unit 103 (1) generation of a photo data set at the time of uploading a photo, (2) determination of whether the photo is open or not, and (3) a photo corresponding to a photo browsing request from the mobile terminal 400 And release.
  • the public photo management unit 103 generates a photo data set upon receiving photo data, a user name of a publishing user, and a user name of a publishing user from the mobile terminal 200, and generates an SNS. Store in the photo database 106.
  • a user ID corresponding to the user name of the disclosure destination user input from the communication unit 104 is extracted from the SNS user database and set.
  • the photo management unit 103 When the public photo management unit 103 receives an input from the response totaling unit 102 that a response has been prepared, the photo management unit 103 creates a photo based on the number of approvals and rejections in the photo data set. Determine whether is public or private. If the public photo management unit 103 determines that the photo is public, the public photo management unit 103 publishes the photo to the mobile terminal 400 of the public user.
  • the public photo management unit 103 displays a photo with the same user ID in the viewable user List of the photo data set as the SNS photo database 106. To generate a photo list. Then, the public photo management unit 103 outputs the generated photo list to the communication unit 104.
  • FIG. 47A is a diagram showing an example of the data structure of a photo list.
  • FIG. 47B is a diagram showing a display example of a photo list displayed on the mobile terminal 400 of the disclosure destination user.
  • the photo list includes a photo ID and a thumbnail of photo data. What is displayed on the screen of the portable terminal 400 is a thumbnail of the photo data.
  • the public photo management unit 103 extracts photo data of the photo data set having the same photo ID from the SNS photo database 106. The data is output to the portable terminal 400 via the communication unit 104.
  • the range in which the server can automatically issue a public approval request can be expanded, and the versatility of the public approval request system of this embodiment can be enhanced. Thereby, it is possible to reduce the time and effort for the publishing source user to specify an approved user different from the subject and make a public approval request to the approved user.
  • Embodiment 4 the publication approval request system 10b of the present embodiment will be described with reference to the drawings.
  • FIG. 20 is a configuration diagram of the server 100b in the public approval request system 10b.
  • the server 100b includes a public photo management unit 103c in addition to the communication unit 104 similar to that in the first embodiment, the answer totaling unit 102a, the SNS photo database 106, the subject detection unit 107, and the feature amount extraction unit 108 similar to those in the second embodiment.
  • the SNS user database 105a of the present embodiment includes the user name, user ID, SNS user contact information, SNS user face feature amount, and proxy user face of the second embodiment.
  • the user name of the proxy user is stored in association with the feature amount of the proxy user's face.
  • the public photo management unit 103c does not generate a photo data set when the photo data is received.
  • the public photo management unit 103c according to the present embodiment generates a photo data set when the subject list is received from the portable terminal 200b after the subject is confirmed using the candidate list in the portable terminal 200b.
  • the process for generating a photo data set is described below.
  • the photograph data set of the present embodiment is the same as the photograph data set shown in FIG. 6B of the second embodiment.
  • the user specifying unit 202 specifies the subject and the disclosure destination user simultaneously with the transmission of the photo data.
  • the approval user and the disclosure destination user are set on the server.
  • the user specifying unit 202a adds the candidate specified by the user input operation as an approved user.
  • the public approval request system 10b has two operations at the time of publishing a photo and browsing a photo, as in the first embodiment.
  • the public photo management unit 103b performs the processing of the public photo management unit 103 according to the first embodiment ((1) generation of a photo data set, (2) determination of photo disclosure / non-disclosure, and (3) photo disclosure).
  • the deformation is as follows. (2) Judgment of whether or not a photo is published and (3) Publication of a photo are the same as those in the first embodiment.
  • Embodiments 1 to 4 there was no answer deadline. In this embodiment, it is confirmed that the answer deadline has been reached, and when the answer deadline is reached, the photo data set is updated even if the answers are not complete. , Determine whether it is public or private.
  • FIG. 31 shows an example of the structure of a photo data set in the SNS photo database 106a.
  • the public photo management unit 103b confirms the response deadline status and the response when the fact that the photo data set has been updated is input from the response totaling unit 102b.
  • the reply deadline status is “after deadline”
  • the public photo management unit 103b sets the public status in the photo data set to “unpublished” when a rejection response is received for a photo whose public status is “public”. Change and stop publishing to public users.
  • the public photo management unit 103b keeps the public status as “unpublished” if there is any rejection, and does not disclose the photo to the public user.
  • the response time limit management unit 111 periodically checks the response time limit in the photo data set when the photo data set is generated in the SNS photo database 106a, and determines whether or not the response time limit has been reached. When the reply deadline has been reached, the reply deadline management unit 111 outputs a photo ID and a reply deadline to the public photo manager 103b.
  • FIG. 30 is a configuration diagram of the mobile terminal 200c in the public approval request system 10c.
  • the mobile terminal 200c is configured to include an answer time limit setting unit 208 in addition to the same photo selection unit 201, user specification unit 202, input unit 203, communication unit 204, and photo database 205 as in the first embodiment.
  • the reply deadline setting unit 208 sets the reply deadline for the public approval request by the input operation of the user who published the photo.
  • FIG. 44 is a diagram showing an example of an answer deadline setting screen displayed on the screen of the mobile terminal 200c of the publisher user.
  • FIG. 46 is a diagram illustrating an example of a public approval request reception screen displayed on the screen of the approval user's mobile terminal 300.
  • the public approval request system 10c has two operations at the time of publishing a photo and browsing a photo, as in the first embodiment.
  • a process for selecting a photograph to be uploaded (S1001) and a process for designating a subject and a destination user (S1002) are executed by the mobile terminal 200a of the publishing user.
  • the processing contents of the processing for selecting a photo to be uploaded and the processing for specifying the subject and the disclosure destination user are the same as those in the first embodiment.
  • the server 100c After changing the response deadline status, the server 100c performs a response counting process after the response deadline (S4006).
  • the server 100c sets the individual answer status and answer of the user whose answer status in the photo data set is “unanswered” to “answered” and “approved”, respectively (S4101).
  • the server 100c increments the number of approvals in the photo data set and updates the photo data set (S4102).
  • the server 100c changes the response status in the photo data set from “requesting approval” to “all responded” (S4103).
  • the server 100c confirms whether or not the number of rejections is zero (S4104). If the number of rejections is zero (Y in S4104), the server 100c changes the publishing status of the photo data set from “unpublished” to “published” (S4105). If the number of rejections is 1 or more (N in S4104), the server 100c terminates without changing the disclosure status.
  • FIG. 37 is a sequence diagram for explaining a process for a reply to a public approval request after the reply deadline (that is, a public / private determination change process). Note that the operation of responding to a public approval request after the response deadline is the same as the operation of changing the response. The former is regarded as “approved” at the time after the reply deadline, and the latter is selected as “approved” or “rejected”, and both the answers are reflected in the photo data set.
  • step S5003 when the change from rejection to approval is accepted from the mobile terminal 300 in step S5003, if all the approval user's responses are approved, the server 100c changes the disclosure status in the photo data set to “ Change from private to public.
  • the public approval request system 10c adds the following process to the process in the first embodiment.
  • a process when a reply is made before the reply deadline a process of substituting “approval” or “reject” into the reply added to the user ID of the authorized user is added.
  • a process when the answer is changed before the answer deadline a process of decrementing the number of previous answers and incrementing the number of new answers is added.
  • the server 100c calculates the sum of the number of approvals and the number of rejections and confirms whether it is equal to the number of approval users (S1105).
  • a photo with GPS information may be disclosed to the first group, and a photo without GPS information may be disclosed to the fourth group.
  • the server sets the disclosure destination user using the friend list, but the present invention is not limited to this.
  • the photograph is also disclosed to the disclosure destination user.
  • a threshold is set, and approval exceeding the threshold is obtained.
  • the information may be disclosed to the disclosure destination user. For example, if the threshold value is 3, and the number of approvals is 3 or more, it is also disclosed to the disclosure destination user. Moreover, even if not all of the users have transmitted the answer, it may be disclosed to the disclosure destination user when the number of approvals exceeds a threshold value. Conversely, the number of rejections may be set as a threshold value. Thereby, it is possible to determine whether or not to publish the photo to the publishing destination user without waiting for all the answers.
  • the threshold setting may be determined by the entire public approval request system. Moreover, even if it determines between a publisher user and an approval user, only a publisher user may decide.
  • the number of approvals serving as a threshold is set, and when approval exceeding the threshold is obtained, it is also disclosed to the disclosure destination user.
  • a value with a weight added to the answer may be calculated, and may be disclosed to the disclosure destination user when a predetermined threshold value is reached.
  • the value is calculated by setting +1 for approval and -1 for refusal, x3 for users with low familiarity in the above modification (3), and x1 for others.
  • a predetermined weighted approval total is set, if the calculated value exceeds the predetermined weighted approval total, it is determined to be public.
  • the result of whether the photograph is disclosed or not disclosed is transmitted to the publishing source user as the result of the authorized user's answer count. You may get a comment on the release together with the answer, and send it as feedback to the publishing user under the approval of the approval user. The approval user is asked for permission to send the comment as feedback or to disclose the user name. For example, in the first embodiment, since the user name of the publishing user is not disclosed to the approved user, the approved user makes a comment that the photograph may be released within the range of common friends. The feedback is transmitted to the publishing user, and the publishing destination of the photo can be changed according to the comment.
  • a pop-up may be displayed on the SNS on the SNS as a notification method when the public approval request is received.
  • the mail address may be stored in the SNS user database and the mail may be transmitted. Thereby, it can be notified by a plurality of means as a method of notifying that the public approval request has been received.
  • the remaining time or the remaining days of the response time limit may be displayed to the approval user.
  • a space for a reply deadline for the public approval request is provided on the home screen after the login of the SNS of the authorized user, and “3 days until reply deadline (1/1)” is displayed. This not only notifies the answer deadline, but also makes it possible to visualize the countdown until the answer deadline, making it easier for the authorized user to be aware of the deadline.
  • a calendar-like schedule may be displayed and the reply deadline for each photo may be described.
  • FIG. 48 shows a calendar display example of the answer deadline.
  • the server 100c executes a process of changing the disclosure status in the photo data set from “public” to “private”. Processing for changing the answer added to the user ID from “approved” to “rejected” may be added. Further, the number of approvals may be decremented and the number of rejections may be incremented. Thereby, when setting the threshold as in the above modification (5) and determining whether to disclose or not disclose, for example, a rejection reply is transmitted later to the published photo, and a new answer is included. Then, the comparison with the threshold value can be performed again to determine whether to continue the publication or to cancel the publication.
  • the mobile terminal 300 has been described as an example of an authorized user terminal, but the present invention is not limited to this.
  • the terminal of the authorized user may be a terminal other than the mobile terminal.
  • the portable terminal 200 and the portable terminal 400 have been described as examples of the terminal of the publishing user and the terminal of the publishing user, the present invention is not limited to this.
  • the terminal of the publishing user and the terminal of the publishing user may be terminals other than the mobile terminal.
  • the configuration for setting the response time limit is added to the configuration of the first embodiment.
  • the configuration for setting the response time limit may be added to the configurations of the second to fourth embodiments. Good.
  • the server determines the proxy user to send the public approval request according to the priority order, and when the answer is not obtained within the response deadline, the server makes a public approval request to the proxy user of the next priority order. May be.
  • an answer cycle (for example, 5 days) is set.
  • the priority is set such that add_sub1 is the highest and add_sub2 to add_subn are sequentially decreased.
  • the server first transmits a public approval request to the contact information of the proxy user of add_sub1. If no answer is obtained even after the number of days set in the answer cycle elapses, the server transmits a public approval request to the contact person of the approval user of the next priority, that is, the proxy user of add_sub2. Similarly, every time the number of days set in the answer cycle elapses, the server determines whether or not an answer has been obtained. If no answer has been obtained, the contact information of the approved user of the next priority is obtained. Send a public approval request to. The server sets the answer setting to “approval” if a reply is not obtained even if the public approval request is sent to the add_subn proxy user.
  • FIG. 45D shows another example of the structure of the SNS user data when a plurality of proxy users are stored.
  • the proxy user does not have a user ID, that is, when the fifth embodiment is applied to the second to fourth embodiments, the SNS of the proxy user (approved user) who represents the proxy user.
  • User data is shown.
  • the contact information of the approved user of the next priority is obtained.
  • the server sets the answer setting to “approval” if a reply is not obtained even if the public approval request is sent to the add_subn proxy user.
  • a proxy deadline for proxying the public approval request may be set in the contact information of the proxy user.
  • the surrogate deadline is, for example, the SNS, such as when the child reaches a predetermined age from the present time (the predetermined age of the child, for example, the birthday of 18 years old), or the scheduled entry date of the SNS user who will be hospitalized.
  • the date and time that the user is expected to be able to reply to the public approval request, or a period such as one week, can be considered.
  • the proxy user's request for public approval request is automatically notified.
  • the contact information of the proxy user may be changed from the destination.
  • a part or all of the components constituting each of the above devices may be configured by one system LSI (Large Scale Integration).
  • the system LSI is an ultra-multifunctional LSI manufactured by integrating a plurality of components on a single chip, and specifically, a computer system including a microprocessor, ROM, RAM, and the like. .
  • a computer program is stored in the RAM.
  • the system LSI achieves its functions by the microprocessor operating according to the computer program.
  • the system LSI is used here, it may be called IC, LSI, super LSI, or ultra LSI depending on the degree of integration. Further, the method of circuit integration is not limited to LSI's, and implementation using dedicated circuitry or general purpose processors is also possible.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.
  • the present invention also provides a computer-readable recording medium such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray ( (Registered trademark) Disc), or recorded in a semiconductor memory or the like.
  • the digital signal may be recorded on these recording media.
  • the present invention can be applied to a server that provides a social network service.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Bioethics (AREA)
  • Tourism & Hospitality (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Quality & Reliability (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

コンテンツの公開を行うサーバにおいて実行される公開承認依頼方法であって、サーバ（１００）は、コンテンツに含まれる被代理ユーザを特定するための第一被代理人情報と被代理ユーザを代理する承認ユーザの連絡先とを対応付けた連絡先情報を含む複数の連絡先情報を有し、サーバ（１００）が、被代理ユーザの第二被代理人情報を取得するステップと、第二被代理人情報と第一被代理人情報とを比較して、複数の連絡先情報から被代理ユーザを代理する承認ユーザの連絡先を抽出するステップと、承認ユーザの連絡先に公開承認依頼を送信するステップとを含む。

Description

公開承認依頼方法、公開承認依頼システムおよび公開承認依頼サーバ
　本発明は、ソーシャルネットワークサービス（ＳＮＳ：Ｓｏｃｉａｌ　Ｎｅｔｗｏｒｋｉｎｇ　Ｓｅｒｖｉｃｅ）上で写真を公開するための技術に関する。
　ＳＮＳには、写真を公開する機能があり、風景や食事の写真、友達と写った写真などが公開されている。このとき、写真を公開する公開ユーザは、公開ユーザが設定した公開範囲に自由に公開することができる（例えば、特許文献３参照）。なお、公開範囲は、ＳＮＳを利用する（ＳＮＳのＩＤを有する）ＳＮＳユーザから選択される。また、以下の説明では、公開範囲に含まれるＳＮＳユーザを公開先ユーザと称する。
　しかし、写真の被写体の中には、被写体本人の許可を得ることなく、関わりのない人にも見え得るＳＮＳ上で写真を公開されることに不快感を抱く人もいる。
　特許文献１によると、議論の参加者が、議論の内容・発言に対し、ネットワーク上で編集を行った際、権限のあるユーザ（例えば、他の議論の参加者）に承認を求め、合意を得た上で編集が反映される。議論の内容・発言を編集した内容が、編集を施した議論の参加者（以下、「編集者」と称する）以外の他の議論の参加者によって承認されれば、他の文書にも反映することができる。
特開２００７－３２８４７１号公報 特許第４５６０４８９号公報 特開２００９－２６５８８５号公報
　上述したように、写真の被写体の中には、写真を公開されることに不快感を抱く人がいることから、ＳＮＳ上で写真を公開する際、写真を公開する公開元ユーザは、被写体に公開していいか否か承認を得ることが望ましい。
　しかし、公開元ユーザが指定した公開範囲へ公開する前に、被写体から承認を得るには、メールあるいはＳＮＳ上のメッセージを用いる等手間がかかる。
　また、特許文献１では、編集者が、承認を求める他の議論の参加者へ連絡をする必要があり、編集者に負担をかけることとなる。
　そのため、公開元ユーザが被写体に、ＳＮＳ上で被写体以外の公開先ユーザへ写真を公開していいか承認を得る際、公開元ユーザの負担を軽減する承認システムが求められている。
　そこで、本発明は、ＳＮＳ上で写真を公開する際、公開元ユーザの負担が少ない公開承認依頼方法および公開承認依頼システム、公開依頼承認サーバを提供することを目的とする。
　本発明の一態様に係る公開承認依頼方法は、コンテンツの公開を行うサーバにおいて実行される公開承認依頼方法であって、前記サーバは、前記コンテンツに含まれる被代理ユーザを特定するための第一被代理人情報と前記被代理ユーザを代理する承認ユーザの連絡先とを対応付けた連絡先情報を含む複数の連絡先情報を有し、前記サーバが、前記被代理ユーザを特定するための第二被代理人情報を取得するステップと、前記サーバが、前記第二被代理人情報と前記第一被代理人情報とを比較して、前記複数の連絡先情報から前記被代理ユーザを代理する前記承認ユーザの連絡先を抽出するステップと、前記サーバが、前記承認ユーザの連絡先に公開承認依頼を送信するステップとを含む。
　なお、これらの全般包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　これにより、公開元ユーザは、承認を得るべきユーザである承認ユーザの一人ひとりに承認を求める必要がなくなる。つまり、公開元ユーザは手間をかけずに承認ユーザの承認状況に合わせて、公開先ユーザへ写真を公開できる。
　本発明によれば、ＳＮＳ上で写真を公開する際、公開元ユーザの負担が少ない公開承認依頼方法および公開承認依頼システム、公開依頼承認サーバを提供することができる。
図１は、実施の形態１における公開承認依頼システム１０の構成図である。 図２は、実施の形態１におけるサーバ１００の構成図である。 図３は、実施の形態１における携帯端末２００の構成図である。 図４は、実施の形態１における携帯端末３００の構成図である。 図５は、実施の形態１における承認ユーザ指定画面の一例を示す図である。 図６Ａは、実施の形態１におけるＳＮＳ写真データベース内の写真データセットの構造の一例を示す図である。 図６Ｂは、実施の形態２におけるＳＮＳ写真データベース内の写真データセットの構造の一例を示す図である。 図７は、実施の形態１における写真データセット内の公開状況、回答状況の遷移を示す図である。 図８は、実施の形態１における公開承認依頼システム１０の写真公開時の動作を示すシーケンス図である。 図９は、実施の形態１における公開承認依頼システム１０の写真公開時の動作を示すシーケンス図である。 図１０は、実施の形態１におけるサーバ１００による回答集計処理の動作を示すフローチャートである。 図１１は、実施の形態１における公開承認依頼システム１０の写真閲覧時の動作を示すシーケンス図である。 図１２は、実施の形態１におけるサーバ１００による写真一覧生成処理のフローチャートである。 図１３は、実施の形態２における公開承認依頼システム１０ａの構成図である。 図１４は、実施の形態２におけるサーバ１００ａの構成図である。 図１５は、実施の形態２における携帯端末２００ａの構成図である。 図１６は、実施の形態２における公開承認依頼システム１０ａの写真公開時の動作を示すシーケンス図である。 図１７は、実施の形態２における公開承認依頼システム１０ａの写真公開時の動作を示すシーケンス図である。 図１８は、実施の形態２におけるサーバ１００ａによる被写体検出処理の動作を示すフローチャートである。 図１９は、実施の形態３における公開承認依頼システム１０ｂの構成図である。 図２０は、実施の形態３におけるサーバ１００ｂの構成図である。 図２１は、実施の形態３における携帯端末２００ｂの構成図である。 図２２は、実施の形態３における承認ユーザ候補選択画面の一例を示す図である。 図２３は、実施の形態３における承認ユーザ候補Ｌｉｓｔの一例を示す図である。 図２４は、実施の形態３における公開承認依頼システム１０ｂの写真公開時の動作を示すシーケンス図である。 図２５は、実施の形態３における公開承認依頼システム１０ｂの写真公開時の動作を示すシーケンス図である。 図２６は、実施の形態３におけるサーバ１００ｂによる被写体検出処理の動作を示すフローチャートである。 図２７は、実施の形態３におけるサーバ１００ｂによる承認ユーザ設定・追加処理の動作を示すフローチャートである。 図２８は、実施の形態４における公開承認依頼システム１０ｃの構成図である。 図２９は、実施の形態４におけるサーバ１００ｃの構成図である。 図３０は、実施の形態４における携帯端末２００ｃの構成図である。 図３１は、実施の形態４におけるＳＮＳ写真データベース内の写真データセットの構造の一例を示す図である。 図３２は、実施の形態４における公開承認依頼システム１０ｃの回答集計処理の動作を示すフローチャートである。 図３３は、実施の形態４における公開承認依頼システム１０ｃの回答集計処理の動作を示すフローチャートである。 図３４は、実施の形態４における公開承認依頼システム１０ｃの写真公開時の動作を示すシーケンス図である。 図３５は、実施の形態４における公開承認依頼システム１０ｃの写真公開時の動作を示すシーケンス図である。 図３６は、実施の形態４におけるサーバ１００ｃによる期限後回答集計処理の動作を示すフローチャートである。 図３７は、実施の形態４における公開承認依頼システム１０ｃの動作を示すシーケンス図である。 図３８は、実施の形態４におけるサーバ１００ｃによる写真データセットの回答変更処理の動作を示すフローチャートである。 図３９は、実施の形態５における公開承認依頼システム１０ｄの構成図である。 図４０は、実施の形態５におけるサーバ１００ｄの構成図である。 図４１は、実施の形態５におけるサーバ１００ｄによる被写体検出処理の動作を示すフローチャートである。 図４２は、実施の形態５におけるサーバ１００ｄによる被写体検出処理の動作を示すフローチャートである。 図４３は、実施の形態１における携帯端末４００の構成図である。 図４４は、実施の形態５において、公開元ユーザの携帯端末２００ｃで表示される回答期限設定画面の一例を示す図である。 図４５Ａは、実施の形態１における、ＳＮＳユーザデータベース内のデータ構造例を示す図である。 図４５Ｂは、実施の形態２における、ＳＮＳユーザデータベース内のデータ構造例を示す図である。 図４５Ｃは、実施の形態５の変形例における、ＳＮＳユーザデータベース内のデータ構造例を示す図である。 図４５Ｄは、実施の形態５の変形例における、ＳＮＳユーザデータベース内のデータ構造例を示す図である。 図４６は、実施の形態５において、承認ユーザの携帯端末３００で表示される公開承認依頼受信画面の一例を示す図である。 図４７Ａは、実施の形態１における写真一覧のデータ構造例を示す図である。 図４７Ｂは、実施の形態１における公開先ユーザの携帯端末４００に表示される写真一覧の表示例を示す図である。 図４８は、変形例（９）において、承認ユーザの携帯端末で表示される回答期限のカレンダー表示例を示す図である。 図４９は、変形例（１７）において、公開元ユーザの携帯端末で表示される回答期限をカレンダーで設定する画面表示例を示す図である。
　（本発明の基礎となった知見）
　サーバが、自動的に、被写体に対して公開の承認を依頼する場合、被写体がメールアドレスあるいはＳＮＳのＩＤ等の連絡手段を有していること、および、被写体が公開の承認または拒否を適切に判断できることが必要とされる。
　しかし、被写体が幼児等である場合には、連絡手段を有していないこと、および、公開の承認または拒否を適切に判断できない場合があると考えられる。
　このような場合には、サーバは、被写体に対し、公開承認依頼を行うことができないという問題がある。
　このような問題を解決するために、本発明の一態様に係る公開承認依頼方法は、コンテンツの公開を行うサーバにおいて実行される公開承認依頼方法であって、前記サーバは、前記コンテンツに含まれる被代理ユーザを特定するための第一被代理人情報と前記被代理ユーザを代理する承認ユーザの連絡先とを対応付けた連絡先情報を含む複数の連絡先情報を有し、前記サーバが、前記被代理ユーザを特定するための第二被代理人情報を取得するステップと、前記サーバが、前記第二被代理人情報と前記第一被代理人情報とを比較して、前記複数の連絡先情報から前記被代理ユーザを代理する前記承認ユーザの連絡先を抽出するステップと、前記サーバが、前記承認ユーザの連絡先に公開承認依頼を送信するステップとを含む。
　例えば、被写体が幼い子供の場合、承認ユーザは、当該被写体の親であっても構わないと考えられる。つまり、承認ユーザは、被写体の代理ユーザであってもよいと考えられる。
　上記構成の公開承認依頼方法では、例えば、被代理ユーザ（幼児等）が写る写真に対する承認または拒否の承認を、連絡手段を有する承認ユーザ（幼児の親等）に求めるので、公開承認依頼を自動的にかつ適切に行うことが可能になる。
　また、公開元ユーザが、承認を得るべきユーザ一人ひとりに承認を求める手間、あるいは、代理ユーザを特定して代理ユーザ一人ひとりに承認を求める手間を軽減できる。これにより、公開元ユーザは手間をかけずに承認ユーザの承認状況に合わせて、公開先ユーザへ写真を公開できる。
　なお、ここでの第一被代理人情報および第二被代理人情報は、ユーザＩＤ、あるいは、顔の画像の特徴量等である。
　また、例えば、第二被代理人情報を取得するステップでは、前記コンテンツの公開元ユーザの端末から前記第二被代理人情報を受け付けてもよい。
　これにより、写真を公開する際、公開元ユーザが被写体を具体的に指定することができる。
　また、例えば、前記第二被代理人情報を取得するステップは、前記コンテンツが画像を含む場合に、前記第二被代理人情報として前記画像から顔の画像の特徴量を抽出するステップを有してもよい。
　これにより、写真公開の際の公開元ユーザが承認ユーザを指定する手間を省け、写真公開におけるユーザの操作の負担をより軽減できる。なお、承認ユーザの連絡先を抽出するステップでは、顔の特徴量を比較して、複数の連絡先情報から、コンテンツに含まれる被代理ユーザの連絡先情報を抽出する。ここでは、完全な一致だけでなく、一致度がある閾値以上の場合、あるいは、一致度が一番高い連絡先情報を抽出する。
　また、例えば、前記複数の連絡先情報のそれぞれは、前記第一被代理人情報として、前記被代理ユーザの顔の画像の特徴量を含み、前記複数の連絡先情報には、予め優先度が設定され、前記承認ユーザの連絡先を抽出するステップでは、前記複数の連絡先情報のうち優先度の高い連絡先情報から順に、前記第二被代理人情報を取得するステップにおいて抽出された前記顔の画像の特徴量と、前記複数の連絡先情報の前記顔の画像の特徴量のそれぞれと比較することにより、前記承認ユーザの連絡先を抽出してもよい。
　これにより、顔の特徴量の照合時、一致する可能性の高いＳＮＳユーザを優先して照合することが可能になる。これにより、照合回数を低減することができ、処理コストを軽減することが可能になり、サーバの負担を減らすことができる。さらに、より効率的に承認ユーザを決定できるようになる。
　また、例えば、さらに、前記サーバが、検出された前記顔の画像の特徴量を用いて前記被代理ユーザの１または複数の候補を取得し、前記コンテンツの公開元ユーザの端末に前記１または複数の候補を提示するステップを有してもよい。
　これにより、サーバは、公開元ユーザによる被写体の候補が正しいか否かの確認後に、承認ユーザを設定できるため、より確実に承認ユーザへ公開承認依頼を送信することができる。また、サーバが承認ユーザを正確に判断できなかった場合でも、公開元ユーザが確認し修正できる。
　また、例えば、さらに、前記サーバが、前記コンテンツの公開元ユーザの端末から前記公開承認依頼の回答期限を取得するステップと、前記サーバが、前記回答期限に基づき、前記回答期限に到達したか否かを判定するステップと、前記サーバが、前記回答期限に達したか否かの判定結果に基づき、公開または非公開を判断するステップとを有してもよい。
　これにより、回答を無期限に待つのではなく、公開したい時期までに回答を求めることができる。さらに、回答期限までに回答をできない承認ユーザがいた状態で、公開先ユーザへも写真を公開した場合、回答期限後に拒否の回答をした場合でも、写真の公開を中止し回答を反映することができるようになる。
　また、例えば、前記サーバが、前記公開または非公開を判断するステップにおいて公開と判定されている場合において、前記回答期限に達した後、前記承認ユーザの連絡先から拒否の回答を受信した場合、前記回答に基づき、前記コンテンツの公開を中止してもよい。
　これにより、承認ユーザが、一度は承認の回答をしたが、後から拒否の回答をする場合も、写真の公開を中止できるようになる。
　また、例えば、前記複数の連絡先情報は、さらに、代理ユーザの連絡先を備え、さらに、前記サーバが、前記回答期限に達したと判定された後に、前記回答が得られていない前記承認ユーザの連絡先情報から、前記代理ユーザの連絡先を抽出し、前記代理ユーザの連絡先に前記公開承認依頼を送信するステップを有してもよい。
　また、例えば、前記承認ユーザの連絡先を抽出するステップでは、前記被代理ユーザが複数の場合、前記被代理ユーザのそれぞれについて前記承認ユーザの連絡先を抽出し、さらに、前記サーバが、前記承認ユーザの連絡先のそれぞれから前記公開承認依頼の回答を受信するステップと、前記サーバが、前記回答の承認の数と拒否の数とを集計するステップと、前記サーバが、前記承認の数が所定値以上であれば公開、それ以外であれば非公開と判断するステップとを有してもよい。
　このような問題を解決するために、本発明の一態様に係る公開承認依頼システムは、コンテンツの公開を行うサーバと、前記公開承認依頼への回答を生成する端末とを含む公開承認依頼システムであって、前記サーバは、前記コンテンツに含まれる被代理ユーザを特定するための第一被代理人情報と前記被代理ユーザを代理する承認ユーザの連絡先とを対応付けた連絡先情報を含む複数の連絡先情報が記憶された記憶部と、前記被代理ユーザを特定するための第二被代理人情報を取得し、前記第二被代理人情報と前記第一被代理人情報とを比較して、前記複数の連絡先情報から前記被代理ユーザを代理する承認ユーザの連絡先を抽出する連絡先抽出部と、前記承認ユーザの連絡先を用いて公開承認依頼を前記端末に送信し、前記端末から前記回答を受信する回答集計部と、回答結果に応じて公開および非公開の判断を行う公開管理部とを備え、前記端末は、前記公開承認依頼について、承認または拒否の回答を生成する回答生成部を備える。
　このような問題を解決するために、本発明の一態様に係る公開承認依頼サーバは、コンテンツの公開を行う公開承認依頼サーバであって、前記コンテンツに含まれる被代理ユーザを特定するための第一被代理人情報と前記被代理ユーザを代理する承認ユーザの連絡先とを対応付けた連絡先情報を含む複数の連絡先情報が記憶された記憶部と、前記被代理ユーザを特定するための第二被代理人情報を取得し、前記第二被代理人情報と前記第一被代理人情報とを比較して、前記複数の連絡先情報から前記被代理ユーザを代理する承認ユーザの連絡先を抽出する連絡先抽出部と、前記承認ユーザの連絡先を用いて公開承認依頼を前記端末に送信し、前記端末から前記回答を受信する回答集計部と、回答結果に応じて公開および非公開の判断を行う公開管理部とを備える。
　なお、これらの全般包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　以下、本発明の実施の形態について、図面を用いて詳細に説明する。なお、以下で説明する実施の形態は、いずれも本発明の好ましい一具体例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置および接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。本発明は、請求の範囲によって特定される。よって、以下の実施の形態における構成要素のうち、本発明の最上位概念を示す独立請求項に記載されていない構成要素については、本発明の課題を達成するのに必ずしも必要ではないが、より好ましい形態を構成するものとして説明される。
　１．実施の形態１
　本実施の形態における公開承認依頼システムについて、図面を参照しながら説明する。
　以下の説明において、コンテンツは、ＳＮＳ上に公開されるデータであり、例えば、動画あるいは写真等が含まれる。本実施の形態では、コンテンツが写真である場合を例に説明する。
　ＳＮＳユーザは、ＳＮＳを利用するユーザであり、ＳＮＳのユーザＩＤを有している。公開元ユーザ（公開者）は、ＳＮＳ上にコンテンツを公開するＳＮＳユーザである。被写体は、コンテンツに画像が含まれる場合、当該画像に写された人物である。
　承認ユーザは、公開元ユーザがコンテンツの公開承認依頼を行うべきユーザであり、公開または拒否の回答を行うユーザである。なお、承認ユーザは、ＳＮＳユーザである必要はない。被写体のうちの被代理ユーザではないＳＮＳユーザについては、ＳＮＳユーザ本人が承認ユーザとなり、被写体のうちの被代理ユーザについては、被代理ユーザを代理する代理ユーザが承認ユーザとなる。
　代理ユーザは、被代理人を代理するユーザであり、コンテンツの公開および非公開を適切に判断できない人物に代わって、公開承認依頼に対する回答を行うユーザである。
　また、公開先ユーザは、上述したように、公開元ユーザが設定した公開範囲に属するＳＮＳユーザである。
　１．１　公開承認依頼システム１０の全体構成
　本実施の形態の公開承認依頼システムは、公開元ユーザがコンテンツをＳＮＳ上に公開しようとする場合に、サーバが自動的に承認ユーザに対する公開承認依頼、および、写真の公開または非公開等を行う。
　特に、本実施の形態の公開承認依頼システムは、写真（コンテンツの一例）の被写体が幼い子供である場合等、写真の公開または拒否を適切に判断することが困難であるＳＮＳユーザ（以下、適宜「被代理ユーザ」（被代理人）と称する）の場合、被代理ユーザを代理する代理ユーザ（例えば、親）に対して承認依頼を行うように構成されている。なお、本実施の形態では、被代理ユーザがＳＮＳユーザとして登録されている、つまり、被代理ユーザがＳＮＳのユーザＩＤを取得している場合について説明する。
　図１は、本実施の形態の公開承認依頼システム１０の全体構成を示す図である。公開承認依頼システム１０は、サーバ１００（公開承認依頼サーバ）、公開元ユーザの携帯端末２００、承認ユーザの携帯端末３００、および、公開先ユーザの携帯端末４００を備えて構成される。
　サーバ１００と、携帯端末２００、３００、４００とは、ネットワーク５０１、５０２、５０３を介して通信可能に構成されている。ネットワーク５００（ネットワーク５０１、５０２、５０３）としては、携帯電話網やイントラネット、インターネット等、任意のネットワークを利用できる。また、ネットワーク５０１、５０２、５０３は、同じ種類のネットワークでも構わないし、複数種類のネットワークでも構わない。
　１．２　サーバ１００の構成
　図２は、サーバ１００の構成図である。サーバ１００は、連絡先抽出部１０１、回答集計部１０２、公開写真管理部１０３（公開管理部に相当）、通信部１０４、ＳＮＳユーザデータベース１０５、および、ＳＮＳ写真データベース１０６を備えて構成される。ＳＮＳユーザデータベース１０５およびＳＮＳ写真データベース１０６は、記憶部の一例である。
　１．２．１　ＳＮＳユーザデータベース１０５
　ＳＮＳユーザデータベース１０５は、ＳＮＳユーザ毎に、ＳＮＳユーザデータ（連絡先情報に相当）を記憶するためのデータベースである。連絡先情報には、例えば、ＳＮＳユーザのユーザ名、ユーザＩＤ、ＳＮＳユーザ本人の連絡先、および、代理ユーザの連絡先が含まれる。
　図４５Ａは、ＳＮＳユーザデータベース１０５内のＳＮＳユーザデータのデータ構造例を示す図である。ユーザ名、ユーザＩＤは、共にユニークなものである。ＳＮＳユーザの連絡先は、本実施の形態では、ユーザのメールアドレスである。代理ユーザの連絡先は、本実施の形態では、代理ユーザのメールアドレスである。
　ＳＮＳユーザが被代理ユーザではない場合は、ＳＮＳユーザデータには、ユーザ名（ｕｓｅｒ＿ｎａｍｅ）、ユーザＩＤ（ｕｓｅｒ＿ｉｄ）、および、ＳＮＳユーザ本人の連絡先（ｅｍａｉｌ＿ａｄｄｒｅｓｓ１）が格納される。本実施の形態では、被代理ユーザではないＳＮＳユーザのＳＮＳユーザデータについては、代理ユーザの連絡先（ｅｍａｉｌ＿ａｄｄｒｅｓｓ２）には、データが登録されない。
　ＳＮＳユーザが被代理ユーザである場合、ＳＮＳユーザデータには、少なくともユーザ名（ｕｓｅｒ＿ｎａｍｅ）、ユーザＩＤ（ｕｓｅｒ＿ｉｄ）、および、代理ユーザの連絡先（ｅｍａｉｌ＿ａｄｄｒｅｓｓ２）が格納される。この場合、ＳＮＳユーザ本人の連絡先（ｅｍａｉｌ＿ａｄｄｒｅｓｓ１）は登録されていなくてもよい。
　ＳＮＳユーザデータベース１０５の参照の目的等は、以下の通りである。ＳＮＳユーザデータベース１０５は、公開元ユーザの携帯端末２００から写真をアップロードする際、サーバ１００の連絡先抽出部１０１が、承認ユーザの携帯端末３００の連絡先を抽出するために参照する。また、サーバ１００内では、ユーザＩＤを扱う。後述する写真データセットの生成時、公開写真管理部１０３が、携帯端末２００から受信した承認ユーザまたは被代理ユーザ、公開先ユーザのユーザ名それぞれに対応するユーザＩＤを抽出するために参照する。
　１．２．２　ＳＮＳ写真データベース１０６
　ＳＮＳ写真データベース１０６は、写真データセットを格納するためのデータベースである。
　図６Ａは、ＳＮＳ写真データベース１０６内の写真データセットの構造例を示す図である。
　写真データセットは、写真１枚につき１つ生成される。
　写真データセットには、公開元ユーザのユーザＩＤ（ｓｈａｒｅｒ）、写真ＩＤ（ｐｈｏｔｏ＿ｉｄ）、公開状況（公開／非公開）（ｓｔａｔｕｓ）、回答状況（承認依頼中／全員回答済）（ａｎｓ＿ｓｔａｔｕｓ）、承認の数（ｏｋ＿ｎｏ）、拒否の数（ｎｇ＿ｎｏ）、承認ユーザの人数（ａｐｐｒｏｖｅｒ＿ｎｏ）、承認ユーザのユーザＩＤ（ａｐｐｒｏｖｅｒｈ（ｈは１以上の整数））、閲覧可能ユーザＬｉｓｔ、および、写真データ（ｐｈｏｔｏ＿ｄａｔａ）等が含まれる。写真ＩＤには、写真１枚毎にユニークな番号が割り振られる。承認ユーザのユーザＩＤには、個別回答状況（未回答／回答済）（ｒｅｓ）が付加されている。
　閲覧可能ユーザＬｉｓｔには、写真ＩＤ（ｐｈｏｔｏ＿ｉｄ）、閲覧可能ユーザのユーザＩＤが含まれ、閲覧可能ユーザは、公開元ユーザ（ｕｓｅｒ＿ｉｄ１）、承認ユーザのユーザＩＤ（ｕｓｅｒ＿ｉｄ２～ｋ）、被代理ユーザのユーザＩＤ（ｕｓｅｒ＿ｉｄｋ＋１～ｍ）、および、公開先ユーザのユーザＩＤ（ｕｓｅｒ＿ｉｄｍ＋１～ｎ）からなる。ここで、図６Ａに示す写真データセットにおける公開先ユーザは、承認ユーザおよび被代理ユーザも公開先ユーザの欄に記載すると重複記載となるため、携帯端末２００により指定された公開先ユーザから、承認ユーザおよび被代理ユーザに含まれているユーザを除いたものとなっている。
　ＳＮＳ写真データベース１０６の参照の目的等は、以下の通りである。ＳＮＳ写真データベース１０６は、通信部１０４から出力される写真データを写真データセットに記憶する。ＳＮＳ写真データベース１０６は、連絡先抽出部１０１から承認ユーザのユーザＩＤを受け付けて、写真データセットに記憶する。ＳＮＳ写真データベース１０６は、承認ユーザ全員から承認の回答があった場合、公開写真管理部１０３により、公開先ユーザを確認するために参照される。さらに、サーバ１００が写真閲覧依頼を受信した場合、公開写真管理部１０３により、写真一覧を生成するために参照される。また、ＳＮＳ写真データベース１０６は、公開写真管理部１０３が写真一覧から選択された写真ＩＤを受信した場合に、受信した写真ＩＤの一致する写真の写真データを抽出するために参照される。
　ＳＮＳ写真データベース１０６は、回答集計部１０２により更新される。回答集計部１０２は、公開承認依頼に対する回答を得た際、回答（承認／拒否）の数をインクリメントするためにＳＮＳ写真データベース１０６を参照し、更新する。また、ＳＮＳ写真データベース１０６は、サーバ１００が携帯端末３００へ公開承認依頼を送信した際、承認ユーザ全員の回答が揃った際に、更新される。
　１．２．３　連絡先抽出部１０１
　連絡先抽出部１０１は、携帯端末２００の公開元ユーザが写真をアップロードする際、通信部１０４から写真データの被写体名、および、公開元ユーザのユーザ名を受け付ける。
　連絡先抽出部１０１は、さらに、入力された被写体名が記憶されたＳＮＳユーザデータを、ＳＮＳユーザデータベース１０５から検索する。
　連絡先抽出部１０１は、承認ユーザの連絡先を抽出する。具体的には、連絡先抽出部１０１は、被写体名が記憶されたＳＮＳユーザデータに代理ユーザの連絡先が記憶されている場合（被代理ユーザの場合）、代理ユーザの連絡先を承認ユーザの連絡先として抽出する。連絡先抽出部１０１は、被写体名が記憶されたＳＮＳユーザデータに代理ユーザの連絡先が記憶されていない場合（被代理ユーザではない場合）、ＳＮＳユーザ本人の連絡先を承認ユーザの連絡先として抽出する。
　そして、連絡先抽出部１０１は、ＳＮＳユーザデータベース１０５から抽出した承認ユーザの連絡先、および、承認ユーザのユーザＩＤを、回答集計部１０２へ出力する。連絡先抽出部１０１は、ＳＮＳユーザデータベース１０５から抽出した承認ユーザの連絡先を、公開写真管理部１０３に出力する。
　１．２．４　回答集計部１０２
　回答集計部１０２は、（１）写真の公開に対する承認を求める公開承認依頼を承認ユーザの携帯端末３００へ送信する公開承認依頼の送信と、（２）当該公開承認依頼に対する回答を携帯端末３００から受信し集計する回答の集計とを行う。
　（１）公開承認依頼の送信
　回答集計部１０２は、サーバ１００が承認ユーザの携帯端末３００へ公開承認依頼を送信する際、連絡先抽出部１０１から入力された承認ユーザの連絡先に、通信部１０４から入力された写真データ、公開元ユーザのユーザ名、公開承認依頼を通信部１０４へ出力する。回答集計部１０２は、同時に、公開写真管理部１０３へ、公開承認依頼を送信した旨を出力する。
　（２）回答の集計
　また、回答集計部１０２は、携帯端末３００のユーザから公開承認依頼に対する回答を受信した際、受信した回答を行ったＳＮＳユーザのユーザＩＤが、後述する写真データセット内に記憶された承認ユーザＩＤに含まれるか否かを確認する。回答集計部１０２は、受信したユーザＩＤが、承認ユーザに含まれるユーザＩＤであり、かつ、後述する写真データセット内の個別回答状況ｒｅｓが「未回答」であれば、個別回答状況ｒｅｓを「回答済」に変更する。そして、回答集計部１０２は、通信部１０４から入力された回答に基づき、承認の数または拒否の数をインクリメントする。回答には「承認」と「拒否」との２つがあり、回答集計部１０２は、承認、拒否、それぞれの数をカウントする。カウントした数は、写真データセット内に記録される。回答集計部１０２は、承認の数または拒否の数インクリメントする毎に、承認の数と拒否の数の合計と写真データセット内の承認ユーザの人数とを比較する。回答集計部１０２は、承認の数と拒否の数の合計と写真データセット内の承認ユーザの人数が一致したとき、承認ユーザ全員の回答が揃ったとみなす。回答集計部１０２は、全員分の回答が揃うと回答を集計し、回答が揃った旨を公開写真管理部１０３へ出力する。
　１．２．５　公開写真管理部１０３
　公開写真管理部１０３は、（１）写真のアップロード時における写真データセットの生成と、（２）写真の公開および非公開の判定と、（３）携帯端末４００からの写真閲覧依頼に対応した写真の公開とを行う。
　（１）写真データセットの生成
　公開写真管理部１０３は、携帯端末２００から、写真データ、公開先ユーザのユーザ名および公開元ユーザのユーザ名を受け付けた際に、写真データセットを生成し、ＳＮＳ写真データベース１０６に格納する。
　公開写真管理部１０３は、写真データセットを生成する際に、連絡先抽出部１０１から承認ユーザのユーザＩＤを受け付ける。さらに、公開写真管理部１０３は、公開元ユーザのユーザ名が記憶されたＳＮＳユーザデータをＳＮＳユーザデータベース１０５から検索し、公開元ユーザのユーザＩＤを取得する。
　公開写真管理部１０３は、写真データ、公開先ユーザのユーザＩＤ、承認ユーザのユーザＩＤおよび公開元ユーザのユーザＩＤ等を含む写真データセットを生成する。
　また、公開写真管理部１０３は、回答集計部１０２から公開承認依頼を送信した旨の情報を受け付けると、写真データセット内の回答状況に「公開承認依頼中」を設定する。
　公開写真管理部１０３は、図６Ａに示す写真データセットの生成時には、初期値を設定する。公開状況ｓｔａｔｕｓの初期値を「非公開」、承認の数ｏｋ＿ｎｏの初期値をゼロ、拒否の数ｎｇ＿ｎｏの初期値をゼロとする。このとき、回答状況ａｎｓ＿ｓｔａｔｕｓは設定しない（言い換えると、例えば、データが空であることを示すＮＵＬＬが設定される）。公開元ユーザのユーザＩＤ　ｓｈａｒｅｒには、公開元ユーザのユーザＩＤを設定する。また、承認ユーザのユーザＩＤ　ａｐｐｒｏｖｅｒｈには、連絡先抽出部１０１から出力された承認ユーザのユーザＩＤを設定する。承認ユーザのユーザＩＤに付加される個別回答状況ｒｅｓには「未回答」を設定する。承認ユーザの人数ａｐｐｒｏｖｅｒ＿ｎｏは、受信した承認ユーザＩＤの数をカウントし設定する。閲覧可能ユーザＬｉｓｔ内の公開先ユーザのユーザＩＤには、通信部１０４から入力された公開先ユーザのユーザ名に対応するユーザＩＤをＳＮＳユーザデータベースから抽出し設定する。
　そして、公開写真管理部１０３は、回答集計部１０２から公開承認依頼を送信した旨を受信した際、写真データセット内の回答状況に「承認依頼中」を代入する。
　（２）写真の公開および非公開の判定
　公開写真管理部１０３は、回答集計部１０２から回答が揃った旨を入力されると、写真データセット内の承認の数、拒否の数に基づき、写真の公開または非公開を判断する。公開写真管理部１０３は、公開と判断した場合は、公開先ユーザの携帯端末４００へ写真を公開する。
　具体的には、公開写真管理部１０３は、回答集計部１０２から回答が揃った旨を入力されると、写真データセットを基に集計を行い、集計結果によって公開の判断をする。集計は、承認の数ｏｋ＿ｎｏと承認ユーザの人数ａｐｐｒｏｖｅｒ＿ｎｏを比較することで行う。公開写真管理部１０３は、承認の数ｏｋ＿ｎｏと承認ユーザの人数ａｐｐｒｏｖｅｒ＿ｎｏとが等しければ全員が承認の回答をしたとみなす。公開写真管理部１０３は、また、承認の数ｏｋ＿ｎｏが承認ユーザの人数ａｐｐｒｏｖｅｒ＿ｎｏより少なければ、「拒否」の回答があったとみなす。公開写真管理部１０３は、全員承認の回答ならば、写真データセットの公開状況ｓｔａｔｕｓを「非公開」から「公開」に変更し、写真データセットの閲覧可能ユーザＬｉｓｔ内の公開先ユーザへも写真を公開する。公開写真管理部１０３は、本実施の形態では、一人でも拒否の回答を送信すれば、公開状況は「非公開」のままとし、公開先ユーザへは写真を公開しない。公開写真管理部１０３は、集計を行うと、回答集計結果を通信部１０４へ出力する。回答集計結果は、写真データセット内の公開状況であり、「公開」または「非公開」を示すデータである。各承認ユーザの回答内容は、本実施の形態では、サーバ１００のみで管理されている。
　写真データセット内の公開状況、回答状況の遷移を図７に示す。
　写真データセット生成時、公開状況ｓｔａｔｕｓには「非公開」が設定され、公開承認依頼が送信された後、回答状況ａｎｓ＿ｓｔａｔｕｓには「承認依頼中」が設定される（ステップＳ１０１）。公開写真管理部１０３は、回答集計処理の際、承認の数と拒否の数との合計（ｏｋ＿ｎｏ＋ｎｇ＿ｎｏ）と、承認ユーザの人数ａｐｐｒｏｖｅｒ＿ｎｏとを比較する（ステップＳ１０２）。公開写真管理部１０３は、ステップＳ１０２において、承認の数と拒否の数の合計（ｏｋ＿ｎｏ＋ｎｇ＿ｎｏ）が承認ユーザの人数ａｐｐｒｏｖｅｒ＿ｎｏと等しくなれば（ステップＳ１０２でｏｋ＿ｎｏ＋ｎｇ＿ｎｏ＝ａｐｐｒｏｖｅｒ＿ｎｏ）、回答状況ａｎｓ＿ｓｔａｔｕｓを「承認依頼中」から「全員回答済」に変更する（ステップＳ１０３）。公開写真管理部１０３は、承認の数と拒否の数の合計（ｏｋ＿ｎｏ＋ｎｇ＿ｎｏ）が承認ユーザの人数ａｐｐｒｏｖｅｒ＿ｎｏより少なければ（ステップＳ１０２でｏｋ＿ｎｏ＋ｎｇ＿ｎｏ＜ａｐｐｒｏｖｅｒ＿ｎｏ）、引き続き初期値の状態「承認依頼中」を保つ。
　公開写真管理部１０３は、回答状況ａｎｓ＿ｓｔａｔｕｓが「全員回答済」になると、拒否の数ｎｇ＿ｎｏを確認する（ステップＳ１０４）。公開写真管理部１０３は、拒否の数ｎｇ＿ｎｏがゼロであれば（ステップＳ１０４でＹ）、公開状況ｓｔａｔｕｓを「非公開」から「公開」に変更する（ステップＳ１０５）。公開写真管理部１０３は、拒否の数がゼロでなければ（ステップＳ１０４でＮ）、公開状況ｓｔａｔｕｓは「非公開」のままとなる（ステップＳ１０６）。
　（３）写真の公開
　さらに、公開写真管理部１０３は、携帯端末４００から写真閲覧依頼を受信すると、写真一覧を生成する。
　さらに、公開写真管理部１０３は、通信部１０４から写真閲覧依頼を受信し写真一覧を生成する際には、写真データセット内の公開状況ｓｔａｔｕｓを確認する。公開写真管理部１０３は、公開状況ｓｔａｔｕｓが「公開」のときは、閲覧可能ユーザＬｉｓｔを参照し、公開状況が「非公開」のときは、写真データセット内の公開元ユーザのユーザＩＤと承認ユーザのユーザＩＤとを参照する。
　また、公開写真管理部１０３は、携帯端末４００のユーザのユーザＩＤが閲覧可能ユーザＬｉｓｔに含まれていれば、写真データセットの閲覧可能ユーザＬｉｓｔ内のユーザＩＤの一致する写真をＳＮＳ写真データベース１０６から抽出し、写真一覧を生成する。そして、公開写真管理部１０３は、生成した写真一覧を、通信部１０４へ出力する。
　図４７Ａは、写真一覧のデータ構造例を示す図である。図４７Ｂは、公開先ユーザの携帯端末４００に表示される写真一覧の表示例を示す図である。写真一覧には、写真ＩＤと写真データのサムネイルとが含まれる。携帯端末４００の画面上に表示されるのは、写真データのサムネイルとなる。
　そして、公開写真管理部１０３は、通信部１０４を介して携帯端末４００から写真一覧内の写真ＩＤを入力されると、写真ＩＤが一致する写真データセットの写真データをＳＮＳ写真データベース１０６から抽出し通信部１０４を介して携帯端末４００へ出力する。
　１．２．６　通信部１０４
　通信部１０４は、公開元ユーザによる写真のアップロード時に、写真の公開元ユーザの携帯端末２００から写真データ、写真データの被写体名、公開元ユーザのユーザ名、および、公開先ユーザのユーザ名を受信する。通信部１０４は、連絡先抽出部１０１へ写真データの被写体名を出力する。通信部１０４は、回答集計部１０２へ写真データおよび公開先ユーザのユーザ名を出力する。通信部１０４は、公開写真管理部１０３へ写真データ、公開元ユーザのユーザ名、および、公開先ユーザのユーザ名を出力する。また、通信部１０４は、回答集計部１０２から入力された写真データ、公開元ユーザのユーザ名、公開承認依頼を承認ユーザの携帯端末３００へ送信する。
　通信部１０４は、公開承認依頼に対する回答があった場合に、当該回答と承認ユーザのユーザ名とを携帯端末３００から受信し、回答集計部１０２へ出力する。さらに、通信部１０４は、公開写真管理部１０３から入力された回答集計結果を、公開元ユーザの携帯端末２００へ送信する。
　通信部１０４は、閲覧可能ユーザによる写真閲覧時には、写真を表示する携帯端末４００から、写真閲覧依頼元の閲覧可能ユーザのユーザＩＤと写真閲覧依頼とを受信し、公開写真管理部１０３へ出力する。また、通信部１０４は、公開写真管理部１０３から入力された写真一覧を携帯端末４００へ送信する。さらに、通信部１０４は、携帯端末４００から写真一覧内の写真ＩＤを受信し公開写真管理部１０３へ出力し、公開写真管理部１０３から入力された写真データを携帯端末４００へ出力する。
　１．３　携帯端末２００の構成
　図３は、公開承認依頼システム１０における、公開元ユーザの携帯端末２００の構成図である。携帯端末２００は、写真選択部２０１、ユーザ指定部２０２、入力部２０３、通信部２０４、および、写真データベース２０５を備えて構成される。
　１．３．１　写真選択部２０１
　写真選択部２０１は、携帯端末２００の公開元ユーザが写真を公開する際、携帯端末２００の公開元ユーザの入力動作によって、写真データベース２０５から写真データを選択し、ユーザ指定部２０２へ出力する。
　１．３．２　ユーザ指定部２０２
　ユーザ指定部２０２は、（１）被写体を指定する処理、（２）公開先ユーザを指定する処理、および、（３）写真等を送信する処理を実行する。
　（１）被写体を指定する処理
　図５は、被写体を指定する際の指定画面の例を示す図である。図５は、特に、友人として登録されたＳＮＳユーザの一欄を示す友人一欄を示している。図５に示す友人一欄には、友人毎に、友人名とチェックボックスとが表示されている。これにより、公開元ユーザは、被写体に対応するチェックボックスにチェックを入れる操作を行うことで、被写体を指定できる。図５では、５７人の友達の中から、Ａが被写体として指定されている。なお、図５では、友人一欄について例示したが、これに限るものではない。職場あるいは学校等、他の一欄であってもよい。
　（２）公開先ユーザを指定する処理
　ユーザ指定部２０２は、さらに、公開先ユーザを指定する。なお、公開先ユーザの指定は、例えば、友人一欄等の一欄毎に公開の範囲を設定するように構成してもよいし、公開先ユーザのグループを写真毎に設定できるように構成してもよい。また、初期設定として友人として登録されているＳＮＳユーザを設定してもよい。
　（３）写真等を送信する処理
　ユーザ指定部２０２は、写真選択部２０１から入力された写真データ、公開元ユーザの入力動作によって指定された被写体名および公開先ユーザのユーザ名を通信部２０４へ出力する。
　１．３．３　入力部２０３
　入力部２０３は、携帯端末２００の公開元ユーザの入力動作によって写真が選択されると、当該入力内容を写真選択部２０１へ出力する。入力部２０３は、携帯端末２００の公開元ユーザの入力動作によって被写体および公開先ユーザが指定されると、当該入力内容を写真選択部２０１へ出力する。
　１．３．４　通信部２０４
　通信部２０４は、ユーザ指定部２０２から入力された写真データ、被写体名、公開先ユーザのユーザ名および公開元ユーザのユーザ名をサーバ１００へネットワーク５００を介して送信する。また、回答集計結果をサーバ１００から受信し、ユーザ指定部２０２へ出力する。
　１．３．５　写真データベース２０５
　写真データベース２０５は、携帯端末２００のユーザの所有する写真を格納している。写真データベース２０５は、携帯端末２００のユーザが写真をアップロードする際、写真選択部２０１により、写真選択のために参照される。
　１．４　携帯端末３００
　図４は、公開承認依頼システム１０における、公開先ユーザへの写真の公開を承認する承認ユーザの携帯端末３００の構成図である。携帯端末３００は、公開承認依頼をサーバ１００からネットワーク５００を介して受信し、回答をサーバ１００へ送信する。携帯端末３００は、回答生成部３０１、入力部３０２、および、通信部３０３を備えて構成される。
　１．４．１　回答生成部３０１
　回答生成部３０１は、サーバ１００から写真データ、公開元ユーザのユーザ名、公開承認依頼を受信した際、入力部３０２から入力された内容を基に承認または拒否を示す回答を生成し、承認ユーザのユーザＩＤと当該回答とを通信部３０３へ出力する。
　１．４．２　入力部３０２
　入力部３０２は、携帯端末３００のユーザが公開承認依頼に対して回答をする際、携帯端末３００のユーザの入力動作によって選択された承認または拒否の入力内容を回答生成部３０１へ出力する。
　１．４．３　通信部３０３
　通信部３０３は、写真データ、公開元ユーザのユーザ名、公開承認依頼をサーバ１００からネットワーク５００を介して受信し、回答生成部３０１へ出力する。また、回答生成部３０１から入力されたユーザＩＤと公開承認依頼に対する回答とをサーバ１００へ送信する。
　１．５　携帯端末４００
　図４３は、公開承認依頼システム１０における、公開された写真を閲覧する公開先ユーザの携帯端末４００の構成図である。携帯端末４００は、公開された写真一覧をサーバ１００からネットワーク５００を介して受信する。また、携帯端末４００は、写真一覧のうちの選択した写真についての写真閲覧依頼を、サーバ１００へネットワーク５００を介して送信し、写真を受信する。携帯端末４００は、公開写真表示部４０１、写真閲覧依頼部４０２、通信部４０３、表示部４０４、および、入力部４０５を備えて構成される。
　１．５．１　公開写真表示部４０１
　公開写真表示部４０１は、承認ユーザから承認を得られ公開された写真を、サーバ１００から受信した際、通信部４０３から入力された内容を基に公開元ユーザのユーザ名と写真データとを表示部４０４に出力する。
　１．５．２　写真閲覧依頼部４０２
　写真閲覧依頼部４０２は、携帯端末４００のユーザがサーバ１００上の写真を閲覧する際、入力部４０５から入力された携帯端末４００のユーザのユーザＩＤと写真閲覧依頼とを通信部４０３へ出力する。また、サーバ１００から写真一覧を受信した際、入力部４０５から入力された内容を基に写真一覧の中から写真を選択する。写真閲覧依頼部４０２は、入力部４０５から入力された写真ＩＤを、サーバ１００に送信するために通信部４０３へ出力する。また、写真閲覧依頼部４０２は、通信部４０３を介してサーバ１００から送信された写真データを受信する。
　１．５．３　通信部４０３
　通信部４０３は、承認ユーザから承認を得られ公開された写真を、サーバ１００からネットワーク５００を介して受信し、公開写真表示部４０１へ出力する。また、写真閲覧時、写真閲覧依頼部４０２から入力された携帯端末４００のユーザ（公開先ユーザ）のユーザＩＤと写真閲覧依頼とをサーバ１００へ送信する。さらに、サーバ１００から写真一覧を受信し写真閲覧依頼部４０２へ出力する。写真閲覧依頼部４０２から入力された写真ＩＤをサーバ１００へ送信し、写真データをサーバ１００から受信し、写真閲覧依頼部４０２へ出力する。
　１．５．４　表示部４０４
　表示部４０４は、携帯端末４００が承認ユーザから承認を得られ公開された写真をサーバ１００から受信した際、公開写真表示部４０１から入力された公開元ユーザのユーザ名と写真データとを携帯端末４００の画面に表示する。
　１．５．５　入力部４０５
　入力部４０５は、携帯端末４００のユーザの入力動作によって入力された携帯端末４００のユーザのユーザＩＤと写真閲覧依頼とを写真閲覧依頼部４０２へ出力する。また、携帯端末４００がサーバ１００から写真一覧を受信した際、携帯端末４００のユーザの入力動作によって、写真一覧から選択された写真の写真ＩＤを写真閲覧依頼部４０２へ出力する。
　１．６　公開承認依頼システム１０の動作
　公開承認依頼システム１０の動作には、写真公開時および写真閲覧時の２つの動作がある。ここで、公開とは、閲覧可能なユーザが、写真を見たいときにサーバ１００へ依頼し、許可を受け写真を閲覧できる状態のことである。以下、２つの動作について図面を参照しながら説明する。
　１．６．１　写真公開処理
　公開承認依頼システム１０の写真公開時の動作について、図８、図９に示すシーケンス図を用いて説明する。図８および図９は、写真公開時の動作を示すシーケンス図である。
　携帯端末２００は、写真を公開する公開元ユーザがサーバ１００へ写真をアップロードする際、アップロードする写真を写真データベースから選択する（Ｓ１００１）。さらに、携帯端末２００は、被写体および公開先ユーザを指定する（Ｓ１００２）。そして、写真データ、被写体名、および、公開先ユーザのユーザ名をサーバ１００へ送信する（Ｓ１００３）。
　サーバ１００は、携帯端末２００から写真データ、被写体名、および、公開先ユーザのユーザ名を受信すると、写真データセットを生成し、写真データベース２０５に格納する（Ｓ１００４）。サーバ１００は、被写体名を用いて承認ユーザの連絡先をＳＮＳユーザデータベースから抽出する（Ｓ１００５）。そして、サーバ１００は、承認ユーザの携帯端末３００へ写真データ、公開元ユーザのユーザ名、公開承認依頼を送信する（Ｓ１００６）。
　携帯端末３００は、サーバ１００から公開承認依頼を受信した際、携帯端末３００のユーザ以外のユーザへの公開について回答（承認または拒否）を選択する（Ｓ１００７）。そして、携帯端末３００は、携帯端末３００のユーザのユーザＩＤと回答とをサーバ１００へ送信する（Ｓ１００８）。
　サーバ１００は、携帯端末３００から公開承認依頼に対する回答を受信すると、回答集計処理を行う（Ｓ１００９）。さらに、サーバ１００は、回答集計結果が「公開」か否かを確認する（Ｓ１０１１）。サーバ１００は、承認ユーザ全員が承認の回答であれば（Ｓ１０１１のＹ）、公開先ユーザへも写真を公開する（Ｓ１０１２）。また、サーバ１００は、承認ユーザのうち一人でも拒否の回答があれば（Ｓ１０１１のＮ）、公開先ユーザへは写真を公開しない。サーバ１００は、同時に、回答集計処理で設定した公開か非公開かの回答集計結果を携帯端末２００へ送信する（Ｓ１０１０）。
　携帯端末４００は、公開された写真の公開元ユーザのユーザ名と写真データとを表示する（Ｓ１０１３）。
　ここで、サーバ１００が行う回答集計処理の詳細について、図１０に示すフローチャートを用いて説明する。
　まず、サーバ１００は、携帯端末３００から公開承認依頼への回答とユーザＩＤを受信すると、受信したユーザＩＤに一致する承認ユーザＩＤが写真データセットに記憶されているか否かを確認する（Ｓ１１０１）。サーバ１００は、受信したユーザＩＤに一致する承認ユーザＩＤが写真データセットに含まれなければ（Ｓ１１０１のＮ）、回答集計処理を終了する。サーバ１００は、受信したユーザＩＤに一致する承認ユーザＩＤが写真データセットに含まれていれば（Ｓ１１０１のＹ）、写真データセットに記憶された当該ユーザＩＤの個別回答状況が「未回答」であるか否かを確認する（Ｓ１１０２）。サーバ１００は、個別回答状況が「回答済」の場合（Ｓ１１０２のＮ）、回答集計処理を終了する。サーバ１００は、個別回答状況が「未回答」の場合（Ｓ１１０２のＹ）、承認ユーザのユーザＩＤに付加された個別回答状況を「回答済」に変更する（Ｓ１１０３）。そして、サーバ１００は、回答に基づき承認の数または拒否の数をインクリメントし写真データセットを更新する（Ｓ１１０４）。より詳細には、サーバ１００は、承認の回答ならば写真データセット内の承認の数をインクリメントし、拒否の回答ならば写真データセット内の拒否の数をインクリメントする。次に、サーバ１００は、承認の数と拒否の数の合計を出し、承認ユーザの人数と等しいかを確認する（Ｓ１１０５）。サーバ１００は、承認の数と拒否の数との合計が、承認ユーザの人数と等しい場合（Ｓ１１０５のＹ）、写真データセット内の回答状況を「承認依頼中」から「全員回答済」に変更する（Ｓ１１０６）。サーバ１００は、承認の数と拒否の数との合計が、承認ユーザの人数未満の場合（Ｓ１１０５のＮ）、引き続き回答を待ちカウントを続ける。サーバ１００は、回答状況を「全員回答済」に変更すると（Ｓ１１０６）、拒否の数がゼロか否かを確認する（Ｓ１１０７）。サーバ１００は、拒否の数がゼロであれば（Ｓ１１０７のＹ）、写真データセットの公開状況を「非公開」から「公開」に変更し、回答集計処理を終了する（Ｓ１１０８）。サーバ１００は、拒否の数が１以上であれば（Ｓ１１０７のＮ）、公開状況は変更せず回答集計処理を終了する。
　１．６．２　写真閲覧時
　公開承認依頼システム１０の写真閲覧時の動作について、図１１に示すシーケンス図を用いて説明する。図１１は、写真閲覧時の動作を示すシーケンス図である。
　携帯端末４００は、ＳＮＳユーザがＳＮＳ上の写真を閲覧する際、携帯端末４００のユーザのユーザＩＤと写真閲覧依頼とをサーバ１００へ送信する（Ｓ１２０１）。
　サーバ１００は、携帯端末４００からユーザＩＤと写真閲覧依頼とを受信すると、写真一覧生成処理を行う（Ｓ１２０２）。そして、サーバ１００は、閲覧可能な写真一覧を携帯端末４００へ送信する（Ｓ１２０３）。
　携帯端末４００は、サーバ１００から写真一覧を受信すると、写真一覧の中から写真を選択する（Ｓ１２０４）。そして、携帯端末４００は、選択した写真の写真ＩＤをサーバ１００へ送信する（Ｓ１２０５）。
　サーバ１００は、携帯端末４００から写真ＩＤを受信すると、写真ＩＤの一致する写真をＳＮＳ写真データベース１０６から抽出する（Ｓ１２０６）。そして、サーバ１００は、写真データを携帯端末４００へ送信する（Ｓ１２０７）。
　ここで、サーバ１００が行う写真一覧生成処理の詳細について、図１２に示すフローチャートを用いて説明する。
　まず、サーバ１００は、ＳＮＳ写真データベース内の写真データセットを抽出する（Ｓ１３０１）。次に、サーバ１００は、写真データセット内の公開状況を参照する（Ｓ１３０２）。サーバ１００は、公開状況が「公開」ならば（Ｓ１３０２のＹ）、閲覧可能ユーザＬｉｓｔ内の全てのユーザＩＤを参照先に設定する（Ｓ１３０３）。一方、サーバ１００は、公開状況が「非公開」ならば（Ｓ１３０２のＮ）、写真データセット内の公開元ユーザＩＤ、被代理ユーザのユーザＩＤおよび承認ユーザＩＤを参照先に設定する（Ｓ１３０４）。そして、サーバ１００は、参照先に設定したユーザＩＤに受信した依頼元のユーザＩＤと同じユーザＩＤがあるか否かを確認する（Ｓ１３０５）。サーバ１００は、参照先に設定したユーザＩＤに依頼元のユーザＩＤと同じユーザＩＤがあれば（Ｓ１３０５のＹ）、写真データのサムネイルを写真一覧に追加する（Ｓ１３０６）。一方、サーバ１００は、参照先に設定したユーザＩＤに依頼元のユーザＩＤと同じユーザＩＤがなければ（Ｓ１３０５のＮ）、ステップＳ１３０６を実行せず、ステップＳ１３０７に移行する。さらに、サーバ１００は、未検索の写真データセットが他にあるかを確認する（Ｓ１３０７）。サーバ１００は、未検索の写真データセットが他にある場合（Ｓ１３０７のＹ）、他の写真データセットを抽出する（Ｓ１３０１）。サーバ１００は、未検索の写真データセットが他にない場合（Ｓ１３０７のＮ）、写真一覧生成処理を終了する。
　１．７　実施の形態１の効果
　本実施の形態では、写真を公開する公開元ユーザが写真を公開する際、選択した写真に対して被写体と公開先ユーザとを指定し、サーバが承認ユーザを自動的に抽出し、当該承認ユーザに対し、公開先ユーザへ公開することについての公開承認依頼を自動的に送信する。これによって、公開元ユーザが、承認を得るべきユーザ一人ひとりに承認を求める手間を軽減している。
　特に、本実施の形態では、写真の被写体本人ではなく、他に承認ユーザを設定し、当該承認ユーザに対して、公開承認依頼を行うことが可能になる。つまり、写真の被写体が幼い子供等、適切に写真の公開および拒否の回答を行えないと考えられる場合でも、当該子供の親等を承認ユーザとすることができる。
　これにより、サーバが公開承認依頼を自動的に行うことができる範囲を広げ、本実施の形態の公開承認依頼システムの汎用性を高めることができる。これにより、公開元ユーザが、被写体とは異なる承認ユーザを特定し、当該承認ユーザに対して公開承認依頼を行う手間を軽減できる。
　また、公開承認依頼に対する回答をサーバ内で集計し、回答集計結果から公開先ユーザに公開するか否かを自動で判断している。これによって、公開元ユーザは手間をかけずに承認ユーザの承認状況に合わせて、公開先ユーザへ写真を公開できる。
　さらに、本実施の形態では、公開元ユーザに開示する回答集計結果は、公開先ユーザに公開するか否かのみとしており、承認ユーザの回答内容を含まない。これによって、どの承認ユーザが承認または拒否の回答をしたかは、公開元ユーザに分からないようになり、承認ユーザは安心して拒否の回答を返すことができる。
　以上、実施の形態では、ＳＮＳ上で写真を公開する際、写真の公開元ユーザが実行するのは被写体と公開先ユーザとを指定するという簡単な作業であり、サーバが自動的に、被写体から承認ユーザを抽出し、公開承認依頼を承認ユーザへ送信する。これにより、ユーザの確認の手間を省くことができる。また、サーバが承認ユーザからの回答を集計し公開を判断することで、ユーザの手間をかけることなく、かつ、回答は秘匿な状態で、承認を求めるべきユーザに配慮して公開先ユーザへも写真を公開することができるという効果がある。
　２．実施の形態２
　本実施の形態の公開承認依頼システム１０ａについて、図面を参照しながら説明する。
　実施の形態１では、公開元ユーザが携帯端末２００において被写体名を指定していたが、本実施の形態では、サーバが写真から被写体を抽出する場合について説明する。
　さらに、実施の形態１では、公開元ユーザが携帯端末２００において公開先ユーザを指定していたが、本実施の形態では、サーバ１００ａが公開先ユーザを設定する。具体的には、本実施の形態では、サーバ１００ａは、予め設定された友達一覧から、承認ユーザおよび被代理ユーザを除いた範囲を公開先ユーザの初期値として設定する。友達一覧は、ＳＮＳユーザ毎に設定された友達のユーザＩＤのリストである。
　また、本実施の形態では、被代理ユーザがユーザＩＤを持っていない場合を想定している。
　２．１　公開承認依頼システム１０ａの全体構成
　図１３は、公開承認依頼システム１０ａの全体構成を示す図である。公開承認依頼システム１０ａは、実施の形態１と同様の携帯端末３００、携帯端末４００、実施の形態１と異なるサーバ１００ａ、携帯端末２００ａを備えて構成される。
　２．２　サーバ１００ａの構成
　図１４は、公開承認依頼システム１０ａにおけるサーバ１００ａの構成図である。サーバ１００ａは、実施の形態１と同様の通信部１０４、ＳＮＳ写真データベース１０６、実施の形態１とは異なる連絡先抽出部１０１ａ、回答集計部１０２ａ、公開写真管理部１０３ａ、ＳＮＳユーザデータベース１０５ａに加え、被写体検出部１０７、特徴量抽出部１０８、および、被写体照合部１０９を備えて構成される。被写体検出部１０７、特徴量抽出部１０８、および、被写体照合部１０９は、被写体決定部の一例である。但し、本実施の形態のＳＮＳ写真データベース１０６には、被代理ユーザがユーザＩＤを持っていない場合を想定しているため、被代理ユーザのユーザＩＤは記憶されない。
　２．２．１　ＳＮＳユーザデータベース１０５ａ
　図４５Ｂは、ＳＮＳユーザデータベース１０５ａの構造例を示す図である。
　ＳＮＳユーザデータベース１０５ａは、ＳＮＳユーザデータとして、実施の形態１におけるＳＮＳユーザデータベース１０５と同様のＳＮＳユーザのユーザ名（ｕｓｅｒ＿ｎａｍｅ）、ユーザＩＤ（ｕｓｅｒ＿ｉｄ）、ＳＮＳユーザの連絡先（ｅｍａｉｌ＿ａｄｄｒｅｓｓ１）に加え、ＳＮＳユーザ本人の顔の画像の特徴量のデータ（ｆａｃｅ＿ｍａｉｎ）、および、被代理ユーザの顔の特徴量のデータ（ｆａｃｅ＿ｓｕｂ１）を格納する。なお、被代理ユーザの顔の特徴量のデータは、複数であってもよい。
　また、ＳＮＳユーザデータベース１０５ａは、実施の形態１における参照の目的に加え、公開する写真から被写体を決定する際、被写体照合部１０９が、当該写真データから抽出した被写体の顔の特徴量のそれぞれと、ＳＮＳユーザデータに記憶された顔の特徴量とを照合するために参照される。ＳＮＳユーザ本人および被代理ユーザの顔の画像の特徴量のデータは、例えば、ＳＮＳアカウント作成時に顔写真を登録しておき、当該顔写真から特徴量抽出部１０８が抽出した特徴量を格納する。
　２．２．２　連絡先抽出部１０１ａ
　連絡先抽出部１０１ａは、後述する被写体照合部１０９から入力された承認ユーザＬｉｓｔを基に、ＳＮＳユーザデータベース１０５ａから承認ユーザの連絡先を抽出し、回答集計部１０２ａへ出力する。具体的には、連絡先抽出部１０１ａは、承認ユーザＬｉｓｔに含まれる承認ユーザのユーザＩＤをもつＳＮＳユーザデータを検索し、検索されたＳＮＳユーザデータに記憶されたＳＮＳユーザの連絡先を、承認ユーザの連絡先として抽出する。
　実施の形態１では、通信部１０４から入力された被写体名を基に、ＳＮＳユーザデータベース１０５から承認ユーザの連絡先を抽出したが、本実施の形態では、被写体照合部１０９から入力された被写体のユーザＩＤを基に、承認ユーザの連絡先を抽出する。
　また、連絡先抽出部１０１ａは、承認ユーザのユーザＩＤを回答集計部１０２ａおよび公開写真管理部１０３ａへ出力する。
　２．２．３　回答集計部１０２ａ
　回答集計部１０２ａは、公開承認依頼の送信において、連絡先抽出部１０１ａから入力された承認ユーザの連絡先に、通信部１０４から入力された写真データ、公開元ユーザのユーザ名、および、公開承認依頼を通信部１０４へ出力する。回答集計部１０２ａは、同時に、公開写真管理部１０３ａへ、公開承認依頼を送信した旨を出力する。
　回答集計部１０２ａは、実施の形態１と同様に、回答の集計を行う。
　２．２．４　公開写真管理部１０３ａ
　公開写真管理部１０３ａは、（１）写真データセットの生成と、（２）写真の公開および非公開の判定と、（３）写真の公開とを行う。
　（１）写真データセットの生成
　公開写真管理部１０３ａは、携帯端末２００ａから写真データ、公開先ユーザのユーザ名および公開元ユーザのユーザ名を受信した際に、通信部１０４から入力された写真データを基に、写真データセットを生成し、ＳＮＳ写真データベース１０６に格納する。図６Ｂは、本実施の形態の写真データセットを示す図である。
　写真データセットには、本実施の形態では、実施の形態１と同様の公開元ユーザのユーザＩＤ、写真ＩＤ、公開状況（公開／非公開）、回答状況（承認依頼中／全員回答済）、承認の数、拒否の数、承認ユーザの人数、承認ユーザのユーザＩＤ、写真データ、および、閲覧可能ユーザＬｉｓｔが含まれる。閲覧可能ユーザＬｉｓｔには、写真ＩＤ、および、閲覧可能ユーザのユーザＩＤが含まれる。閲覧可能ユーザには、公開元ユーザ、承認ユーザ、公開先ユーザが含まれる。なお、本実施の形態の写真データセットには、被代理ユーザのユーザＩＤは含まれない。ここで、写真データセットにおける公開先ユーザは、重複記載を避けるため、携帯端末２００ａにより指定された公開先ユーザから承認ユーザを除いたものとなっている。
　ここで、実施の形態１では、携帯端末２００から写真データ、承認ユーザのユーザ名、公開先ユーザのユーザ名を受信した際、写真データセットを生成していた。これに対し、本実施の形態では、写真データおよび公開先ユーザのユーザ名を受信した際、写真データセットを生成する。よって、写真データセット生成時の初期値の設定は、実施の形態１の設定項目から承認ユーザの人数、承認ユーザＩＤのユーザＩＤ、公開先ユーザのユーザＩＤを除いたものとなる。公開元ユーザのユーザＩＤには、公開元ユーザのユーザＩＤを設定する。公開状況は「非公開」を設定し、回答状況は何も設定しない。承認の数はゼロ、拒否の数はゼロとする。
　そして、公開写真管理部１０３ａは、回答集計部１０２ａから承認ユーザのユーザＩＤを入力された際、回答状況、承認ユーザの人数、承認ユーザのユーザＩＤ、公開先ユーザのユーザＩＤを設定する。回答状況には「公開承認依頼中」を設定する。承認ユーザのユーザＩＤには回答集計部１０２ａから入力された承認ユーザのユーザＩＤを、承認ユーザの人数には、承認ユーザのユーザＩＤの総数をカウントし設定する。閲覧可能ユーザＬｉｓｔ内の公開先ユーザには、承認ユーザ以外の公開元ユーザの友達一覧内の全てのユーザＩＤを設定する。
　（２）写真の公開および非公開の判定
　公開写真管理部１０３ａは、回答集計部１０２ａから回答が揃った旨を入力されると、写真データセットを基に集計を行い、集計結果によって公開の判断をする。集計は、「承認」の数と承認ユーザの人数を比較し行う。公開写真管理部１０３ａは、全員承認の回答ならば、写真データセットの公開状況を「非公開」から「公開」に変更し、写真データセットの閲覧可能ユーザＬｉｓｔ内の公開先ユーザへも写真を公開する。一人でも拒否の回答を送信すれば、公開状況は「非公開」のままとし、公開先ユーザへは写真を公開しない。公開写真管理部１０３ａは、集計を行うと、回答集計結果を通信部１０４へ出力する。回答集計結果は、実施の形態１と同様、写真データセット内の公開状況のみとし「公開」または「非公開」である。各承認ユーザの回答内容はサーバ１００ａのみが知っている。
　（３）写真の公開
　公開写真管理部１０３ａは、実施の形態１と同様に、携帯端末４００からの写真閲覧依頼に対応した写真の公開を行う。
　２．２．５　被写体検出部１０７
　被写体検出部１０７は、公開元ユーザの携帯端末２００ａから受信した写真から、全ての被写体の顔の画像を検出し、特徴量抽出部１０８へ出力する。
　２．２．６　特徴量抽出部１０８
　特徴量抽出部１０８は、被写体検出部１０７から入力された被写体の顔の画像から、被写体の顔の画像の特徴量を抽出し、被写体照合部１０９へ出力する。また、特徴量抽出部１０８は、ＳＮＳアカウント作成時、登録された顔写真から、顔の画像の特徴量を抽出しＳＮＳユーザデータベースに格納する。
　２．２．７　被写体照合部１０９
　被写体照合部１０９は、以下の被写体照合処理を実行する。
　以下で、被写体照合処理について、図１８に示すフローチャートを用いて説明する。
　被写体照合部１０９は、特徴量抽出部１０８から入力された被写体の顔の画像の特徴量から、検出した被写体の人数を抽出する（Ｓ２１０１）。被写体照合部１０９は、照合する動作回数をｃとし、初期値にゼロを設定する（Ｓ２１０２）。
　被写体照合部１０９は、現在の照合対象の被写体について、特徴量抽出部１０８から入力された被写体の顔の画像の特徴量を、ＳＮＳユーザデータベース１０５ａ内の複数の顔の画像の特徴量と照合しマッチングを行う（Ｓ２１０３）。照合は、ＳＮＳユーザ本人の顔の特徴量のデータだけでなく、被代理ユーザの顔の特徴量のデータについても実行される。被写体照合部１０９は、照合対象の被写体について、顔の画像の特徴量が一致する顔の特徴量のデータを有するＳＮＳユーザデータがあるか否かを確認する（Ｓ２１０４）。
　被写体照合部１０９は、ステップＳ２１０４において、一致するＳＮＳユーザデータがあれば（Ｓ２１０４のＹ）、そのＳＮＳユーザデータのユーザＩＤを写真データセットの承認ユーザのユーザＩＤに含める（Ｓ２１０５）。被写体照合部１０９は、写真データセット内の公開先ユーザに承認ユーザのユーザＩＤが含まれる場合は、公開先ユーザから当該承認ユーザのユーザＩＤを削除する。
　被写体照合部１０９は、ステップＳ２１０４において、一致するＳＮＳユーザデータがない場合は（Ｓ２１０４のＮ）、ステップＳ２１０６に移行する。
　被写体照合部１０９は、被写体を照合する動作回数ｃをインクリメントする（Ｓ２１０６）。被写体照合部１０９は、照合する動作回数ｃが抽出した被写体の人数に達したか否かを確認する（Ｓ２１０７）。被写体照合部１０９は、照合する動作回数ｃが被写体の人数に達していない場合（Ｓ２１０７のＮ）、特徴量抽出部１０８から受信した被写体の顔の画像の特徴量を、ＳＮＳユーザデータベース１０５ａ内のユーザの顔の画像の特徴量と照合しマッチングを行う（Ｓ２１０３）。
　被写体照合部１０９は、被写体の人数分だけＳ２１０３～Ｓ２１０６の処理を繰り返す。
　被写体照合部１０９は、ステップＳ２１０７において、照合する動作回数ｃが被写体の人数に達している場合（Ｓ２１０７のＹ）、承認ユーザＬｉｓｔが空であるか否かを確認する（Ｓ２１０８）。被写体照合部１０９は、承認ユーザＬｉｓｔが空でなかった場合（Ｓ２１０８のＮ）、承認ユーザＬｉｓｔを公開写真管理部１０３ａへ出力する（Ｓ２１０９）。
　被写体照合部１０９は、さらに、承認ユーザＬｉｓｔ内のすべてのユーザＩＤを連絡先抽出部１０１ａへ出力する（Ｓ２１１０）。被写体照合部１０９は、承認ユーザＬｉｓｔが空であった場合（Ｓ２１０８のＹ）、該当ユーザなしの結果を通信部１０４へ出力し、公開元ユーザへ送信する（Ｓ２１１１）。
　２．３　携帯端末２００ａの構成
　図１５は、公開承認依頼システム１０ａにおける公開元ユーザの携帯端末２００ａの構成図である。携帯端末２００ａは、実施の形態１の携帯端末２００とは、ユーザ指定部２０２を備えない点で異なる。携帯端末２００ａは、実施の形態１と同様の写真選択部２０１、入力部２０３、通信部２０４、および、写真データベース２０５を備えて構成される。
　本実施の形態では、上述したように、携帯端末２００ａがユーザ指定部２０２を備えないため、写真選択部２０１は、選択した写真の写真データを直接通信部２０４へ出力する。
　２．４　公開承認依頼システム１０ａの動作
　公開承認依頼システム１０ａには、実施の形態１と同様に、写真公開時および写真閲覧時の２つの動作がある。
　写真閲覧時の動作については、実施の形態１と同様の処理であるため、説明を省略し、以下で、写真公開時の動作について、図面を参照しながら説明する。
　本実施の形態の公開承認依頼システム１０ａは、実施の形態１の公開承認依頼システム１０とは、写真の公開元ユーザの入力動作に基づいて被写体および公開先ユーザを指定する処理（Ｓ１００２）を行わない点で異なる。本実施の形態の公開承認依頼システム１０ａは、実施の形態１の被写体を指定する処理に代えて、サーバで受信した写真から被写体を検出する被写体照合処理（後述する図１６のＳ２００１）を実行する。さらに、本実施の形態の公開承認依頼システム１０ａでは、実施の形態１の写真データセットを生成する処理（Ｓ１００４）、連絡先を抽出する処理（Ｓ１００５）を変形している。なお、写真データセットにおける公開先ユーザは、サーバ１００ａが予め記憶している公開元ユーザの友達一覧から、承認ユーザを除いた範囲に設定される。連絡先抽出の処理の変形では、被写体検出処理によって特定された承認ユーザの連絡先を抽出する。
　被写体照合処理および変形処理の実行箇所は、公開承認依頼システム１０における携帯端末２００からサーバ１００へ写真データを送信する処理（Ｓ１００３）と抽出した承認ユーザの連絡先へ、写真データ、公開元ユーザのユーザ名、公開承認依頼を送信する処理（Ｓ１００６）との間である。
　公開承認依頼システム１０ａの写真公開時の動作について、図１６、図１７を用いて説明する。図１６および図１７は、写真公開時の動作を示すシーケンス図である。
　公開元ユーザの携帯端末２００ａにより、アップロードする写真を選択する処理（Ｓ１００１）、および、サーバ１００ａへ写真データと公開先ユーザのユーザ名とを送信する処理（Ｓ１００３）が実行される。アップロードする写真を選択する処理、および、サーバ１００ａへ写真データを送信する処理の処理内容は、実施の形態１と同じである。
　サーバ１００ａは、公開元ユーザの携帯端末２００ａから写真データおよび公開先ユーザのユーザ名を受信すると、被写体照合処理を行う（Ｓ２００１）。次に、写真データセットを生成し、ＳＮＳ写真データベースに格納する（Ｓ２００２）。
　さらに、サーバ１００ａは、被写体検出処理で照合し決定した承認ユーザの連絡先をＳＮＳユーザデータベースから抽出する（Ｓ２００３）。サーバ１００ａは、承認ユーザの携帯端末３００へ写真データ、公開元ユーザのユーザ名、公開承認依頼を送信する（Ｓ１００６）。
　図１７に示すステップＳ１００７～ステップＳ１０１３の処理内容は、実施の形態１と同じである。
　２．５　実施の形態２の効果
　実施の形態１では、写真の公開元ユーザが、図５に示す指定画面等を用いて被写体を指定していた。これに対し、本実施の形態では、写真を公開する際、サーバが被写体を自動で抽出し、当該被写体から承認ユーザを決定している。これによって、写真公開の際の公開元ユーザが被写体を指定する手間を省くことができ、写真公開におけるユーザの操作の負担を軽減できる。
　以上、本実施の形態では、写真の公開元ユーザが承認ユーザを指定する手間を省き、承認ユーザへ自動で公開承認依頼を送信できるという効果がある。
　３．実施の形態３
　ここでは、本実施の形態の公開承認依頼システム１０ｄについて、図面を参照しながら説明する。実施の形態２では、被写体とＳＮＳユーザとの顔の画像の特徴量とを照合する際、ＳＮＳユーザデータベース全体のユーザを照合している。これに対し、本実施の形態では、公開元ユーザの友達を優先して照合することで、ＳＮＳユーザデータベース全体を照合するよりも効率よく承認ユーザの抽出を行えるようにしている。
　３．１　公開承認依頼システム１０ｄの全体構成
　図３９は、公開承認依頼システム１０ｄの全体構成を示す図である。公開承認依頼システム１０ｄは、実施の形態１と同様の携帯端末３００、携帯端末４００、実施の形態２と同様の携帯端末２００ａ、および、実施の形態１および２とは異なるサーバ１００ｄを備えて構成される。
　３．２　サーバ１００ｄの構成
　図４０は、公開承認依頼システム１０ｄにおけるサーバ１００ｄの構成図である。サーバ１００ｄは、実施の形態１と同様の公開写真管理部１０３、通信部１０４、実施の形態２と同様の連絡先抽出部１０１ａ、回答集計部１０２ａ、ＳＮＳ写真データベース１０６、被写体検出部１０７、特徴量抽出部１０８、実施の形態２と異なる被写体照合部１０９ｂ、および、実施の形態１および２と異なるＳＮＳユーザデータベース１０５ｂを備えて構成される。
　３．２．１　ＳＮＳユーザデータベース１０５ｂ
　ＳＮＳユーザデータベース１０５ｂは、実施の形態２におけるＳＮＳユーザデータベース１０５ａと同様のＳＮＳユーザのユーザ名（ｕｓｅｒ＿ｎａｍｅ）、ユーザＩＤ（ｕｓｅｒ＿ｉｄ）、ＳＮＳユーザの連絡先（ｅｍａｉｌ＿ａｄｄｒｅｓｓ１）、ＳＮＳユーザの顔の画像の特徴量のデータ（ｆａｃｅ＿ｍａｉｎ）および被代理ユーザの顔の画像の特徴量のデータ（ｆａｃｅ＿ｓｕｂ１）に加え、ユーザの友達一覧を格納している。本実施の形態では、被写体を照合する際、ＳＮＳユーザデータベース１０５ｂにおいて、友達一覧に含まれるＳＮＳユーザのＳＮＳユーザデータが優先的に参照される。また、友達一覧に含まれない被写体がある場合は、友達一覧に含まれるＳＮＳユーザのＳＮＳユーザデータ以外のＳＮＳユーザデータについても参照される。
　３．２．２　被写体照合部１０９ｂ
　被写体照合部１０９ｂは、実施の形態２の被写体照合部１０９の被写体照合処理に代えて、以下の被写体照合処理を実行する。実施の形態２では、ＳＮＳユーザデータベース１０５全体を参照していた。本実施の形態では、被写体照合部１０９ｂは、先ず、ＳＮＳユーザデータベース１０５ｂ内のＳＮＳユーザデータのうち、予め設定された友達一覧に含まれるＳＮＳユーザのＳＮＳユーザデータを参照し、被写体照合処理を行う。被写体照合部１０９ｂは、友人一欄に含まれない被写体がある場合、ＳＮＳユーザデータベース１０５ｂ内の友達一覧以外のＳＮＳユーザのＳＮＳユーザデータを参照する。
　以下で、被写体照合処理について、図４１、図４２に示すフローチャートを用いて説明する。
　被写体照合部１０９ｂは、特徴量抽出部１０８から入力された被写体の顔の画像の特徴量から、検出した被写体の人数を抽出する（Ｓ２１０１）。照合する動作回数をｃとし、初期値に０を設定する（Ｓ２１０２）。
　被写体照合部１０９ｂは、現在の照合対象の被写体について、特徴量抽出部１０８から受信した被写体の顔の画像の特徴量を、ＳＮＳユーザデータベース１０５ｂ内に記憶されたＳＮＳユーザの顔の画像の特徴量うち、友達一覧に含まれるＳＮＳユーザのＳＮＳユーザデータに記憶された顔の画像の特徴量のデータと照合しマッチングを行う（Ｓ６００１）。照合は、ＳＮＳユーザ本人の顔の特徴量のデータだけでなく、被代理ユーザの顔の特徴量のデータについても実行される。被写体照合部１０９ｂは、照合対象の被写体について、顔の画像の特徴量が一致するＳＮＳユーザデータがあるか否かを確認する（Ｓ２１０４）。
　被写体照合部１０９ｂは、ステップＳ２１０４において、一致するＳＮＳユーザデータがあれば（Ｓ２１０４のＹ）、そのＳＮＳユーザデータのユーザＩＤを写真データセットに含めるとともに、承認ユーザＬｉｓｔに当該ＳＮＳユーザのユーザＩＤを記憶する（Ｓ２１０５）。また、被写体照合部１０９ｂは、写真データセット内の公開先ユーザのユーザＩＤに承認ユーザのユーザＩＤが含まれる場合は、公開先ユーザから当該承認ユーザのユーザＩＤを削除する。
　被写体照合部１０９ｂは、ステップＳ２１０４において、一致するＳＮＳユーザデータがない場合は（Ｓ２１０４のＮ）、ステップＳ２１０６に移行する。
　被写体照合部１０９ｂは、被写体を照合する動作回数ｃをインクリメントする（Ｓ２１０６）。被写体照合部１０９ｂは、照合する動作回数ｃが被写体の人数に達したか否かを確認する（Ｓ２１０７）。被写体照合部１０９ｂは、照合する動作回数ｃが被写体の人数に達していない場合（Ｓ２１０７のＮ）、特徴量抽出部１０８から受信した被写体の顔の画像の特徴量を、ＳＮＳユーザデータベース１０５ａ内に記憶されたＳＮＳユーザの顔の画像の特徴量うち、友達一覧に記憶されたＳＮＳユーザデータに記憶された顔の画像の特徴量（ＳＮＳユーザおよび被写体ユーザの両方の顔の画像の特徴量）と照合しマッチングを行う（Ｓ６００１）。
　被写体照合部１０９ｂは、被写体の人数分だけＳ６００１～Ｓ２１０６の処理を繰り返す。
　被写体照合部１０９ｂは、ステップＳ２１０７において、照合する動作回数ｃが被写体の人数に達している場合（Ｓ２１０７のＹ）、被写体全員の照合ができたか否かを確認する（Ｓ６００２）。被写体全員を照合できたか否かの確認は、例えば、承認ユーザＬｉｓｔに含まれるＳＮＳユーザの人数（以下、適宜「第一の照合済みＳＮＳユーザ数」と称する）と被写体の人数とを比較することにより行われる。被写体照合部１０９ｂは、第一の照合済みＳＮＳユーザ数と被写体の人数とが等しい場合に、被写体全員を照合できたと判定する。被写体照合部１０９ｂは、被写体全員の照合ができた場合、つまり、人数が等しい場合（Ｓ６００２のＹ）、決定した承認ユーザの承認ユーザＬｉｓｔを公開写真管理部１０３ａへ出力する（Ｓ２１０９）。
　被写体照合部１０９ｂは、ステップＳ６００２において、被写体全員の照合ができなかった場合、つまり、被写体の人数の方が第一の照合済みＳＮＳユーザ数より多かった場合（Ｓ６００２のＮ）、照合する動作回数をｃ´とし、初期値に０を設定する（Ｓ６００３）。
　被写体照合部１０９ｂは、照合できなかった被写体の顔の画像の特徴量を、ＳＮＳユーザデータベース内に記憶されたＳＮＳユーザの顔の画像の特徴量うち、友達一覧に含まれないＳＮＳユーザのＳＮＳユーザデータに記憶された顔の画像の特徴量と照合しマッチングを行う（Ｓ６００４）。被写体照合部１０９ｂは、照合対象の被写体について、顔の画像の特徴量が一致するＳＮＳユーザデータがあるか否かを確認する（Ｓ６００５）。
　被写体照合部１０９ｂは、ステップＳ６００５において、一致するＳＮＳユーザデータがあれば（Ｓ６００５のＹ）、そのＳＮＳユーザのユーザＩＤを写真データセットに含めるとともに、承認ユーザＬｉｓｔに当該ＳＮＳユーザのユーザＩＤを記憶する（Ｓ６００６）。また、被写体照合部１０９ｂは、写真データセット内の公開先ユーザに承認ユーザのユーザＩＤが含まれる場合は、公開先ユーザから当該承認ユーザのユーザＩＤを削除する。
　被写体照合部１０９ｂは、ステップＳ６００５において、一致するＳＮＳユーザデータがない場合は（Ｓ６００５のＮ）、ステップＳ６００６を実行せず、ステップＳ６００７に移行する。
　被写体照合部１０９ｂは、被写体を照合した動作回数ｃ´をインクリメントする（Ｓ６００７）。照合する動作回数ｃ´が、承認ユーザＬｉｓｔに含まれるＳＮＳユーザの人数（以下、適宜「第二の照合済みＳＮＳユーザ数」と称する）と被写体の人数との差分の数に達したか否かを確認する（Ｓ６００８）。照合する動作回数ｃ´が、第二の照合済みＳＮＳユーザ数と被写体の人数との差分に達していない場合（Ｓ６００８のＮ）、被写体の顔の画像の特徴量と、ＳＮＳユーザデータベース内の公開元ユーザの友達以外の範囲のユーザの顔の画像の特徴量とを照合しマッチングを行う（Ｓ６００４）。
　被写体照合部１０９ｂは、第二の照合済みＳＮＳユーザ数と被写体の人数との差分の回数だけ、ステップＳ６００４～ステップＳ６００７の処理を繰り返す。
　被写体照合部１０９ｂは、ステップＳ６００８において、照合する動作回数ｃ´が第二の照合済みＳＮＳユーザ数と被写体の人数との差分に達した場合（Ｓ６００８のＹ）、承認ユーザＬｉｓｔが空であるか否かを確認する（Ｓ２１０８）。承認ユーザＬｉｓｔが空でなかった場合（Ｓ２１０８のＮ）、承認ユーザＬｉｓｔを公開写真管理部１０３ａへ出力する（Ｓ２１０９）。
　被写体照合部１０９ｂは、承認ユーザＬｉｓｔの公開写真管理部１０３ａへの出力後（Ｓ２１０９の実行後）、承認ユーザＬｉｓｔを連絡先抽出部１０１ａへ出力する（Ｓ２１１０）。被写体照合部１０９ｂは、ステップＳ２１０８において、承認ユーザＬｉｓｔが空であった場合（Ｓ２１０８のＹ）、該当ユーザなしの結果を通信部１０４へ出力し、公開元ユーザへ送信する（Ｓ２１１１）。
　３．３　公開承認依頼システム１０ｄの動作
　公開承認依頼システム１０ｄの動作は、実施の形態２の動作と同様である。ただし、被写体照合処理は、被写体照合部１０９ｂで説明した処理を使用する。
　３．４　実施の形態３の効果
　実施の形態３では、承認ユーザを特定するために、被写体とＳＮＳユーザとの顔の画像の特徴量とを照合する際、公開元ユーザの友達を優先して照合している。
　承認ユーザは、公開元ユーザの友達であることが多いと想定される。また、被代理ユーザは、公開元ユーザの友達、あるいは、友達の子供等であることが多いと想定される。そのため、照合時、ＳＮＳユーザデータベース内のユーザの友達一覧を優先的に参照し、友達一覧の範囲を優先して照合することで、ＳＮＳユーザデータベース全体より狭い範囲で照合することができる。これにより、広い範囲で被写体を照合する処理に比べ処理コストが軽減されるため、サーバの負担を減らすことができる。さらに、より効率的に承認ユーザを決定できるようになる。
　以上、説明したように、実施の形態３では、被写体検出処理における特徴量の照合の際、サーバの負担を減らし、承認ユーザを効率的に決定できるという効果がある。
　４．実施の形態４
　ここでは、本実施の形態の公開承認依頼システム１０ｂについて、図面を参照しながら説明する。
　実施の形態１では、公開元ユーザが承認ユーザを指定し、実施の形態２および３では、サーバが承認ユーザを抽出していた。これに対し、本実施の形態では、実施の形態２と同様に、サーバが写真から被写体を抽出するが、当該被写体から承認ユーザの候補を生成し、公開元ユーザに確認する処理を行う。
　なお、公開先ユーザについては、実施の形態２および３と同様に、サーバ１００ｂが公開先ユーザを設定する。公開先ユーザの設定方法は、実施の形態２および３と同じである。サーバ１００ｂは、友達一覧から承認ユーザを除いた範囲を公開先ユーザの初期値として設定する。
　４．１　公開承認依頼システム１０ｂの全体構成
　図１９は、公開承認依頼システム１０ｂの全体構成を示す図である。公開承認依頼システム１０ｂは、実施の形態１と同様の携帯端末３００、携帯端末４００、実施の形態１～３とは異なるサーバ１００ｂ、および、携帯端末２００ｂを備えて構成される。
　４．２　サーバ１００ｂの構成
　図２０は、公開承認依頼システム１０ｂにおけるサーバ１００ｂの構成図である。サーバ１００ｂは、実施の形態１と同様の通信部１０４、実施の形態２と同様の回答集計部１０２ａ、ＳＮＳ写真データベース１０６、被写体検出部１０７および特徴量抽出部１０８に加え、公開写真管理部１０３ｃ、連絡先抽出部１０１ｂ、被写体照合部１０９ａおよび候補提示部１１０を備えて構成される。なお、図示しないが、本実施の形態のＳＮＳユーザデータベース１０５ａは、実施の形態２のユーザ名、ユーザＩＤ、ＳＮＳユーザの連絡先、ＳＮＳユーザ本人の顔の特徴量、および、被代理ユーザの顔の特徴量に加え、被代理ユーザのユーザ名を被代理ユーザの顔の特徴量に対応付けて記憶している。
　４．２．１　連絡先抽出部１０１ｂ
　連絡先抽出部１０１ｂは、候補提示部１１０から入力された被写体Ｌｉｓｔに基づいて、ＳＮＳユーザデータベース１０５ａから承認ユーザの連絡先を抽出し、回答集計部１０２ａへ出力する。実施の形態２では、連絡先抽出部１０１ａは、被写体照合部１０９から直接入力された承認ユーザＬｉｓｔを基にＳＮＳユーザデータベース１０５ａから承認ユーザの連絡先を抽出していた。本実施の形態では、連絡先抽出部１０１ｂは、被写体照合部１０９ａが抽出した被写体の候補のうち、候補提示部１１０により承認ユーザの候補として公開元ユーザにより選択された被写体の候補について、承認ユーザの連絡先を抽出する。
　具体的には、連絡先抽出部１０１ｂは、被写体Ｌｉｓｔのユーザ名に一致するユーザ名が記憶されたＳＮＳユーザデータに記憶されたＳＮＳユーザの連絡先を、承認ユーザの連絡先として抽出する。
　４．２．２　公開写真管理部１０３ｃ
　公開写真管理部１０３ｃは、実施の形態１における公開写真管理部１０３の処理の写真データセットを生成する処理に代えて、以下の処理を行う。その他の処理は公開写真管理部１０３の処理と同様である。実施の形態１では、公開写真管理部１０３は、携帯端末２００から、写真データ、被写体名、および、公開先ユーザのユーザ名を受信すると、写真データセットを生成していた。
　なお、本実施の形態では、公開写真管理部１０３ｃは、写真データを受信した時点では写真データセットの生成を行わない。本実施の形態の公開写真管理部１０３ｃは、携帯端末２００ｂにおいて候補Ｌｉｓｔを用いて被写体が確認された後、携帯端末２００ｂから被写体Ｌｉｓｔを受信した際に、写真データセットの生成を行う。
　以下で、写真データセットを生成する処理について説明する。本実施の形態の写真データセットは、実施の形態２の図６Ｂに示す写真データセットと同じである。
　公開写真管理部１０３ｃは、携帯端末２００ｂにおいて候補Ｌｉｓｔを用いて被写体が確認され、携帯端末２００ｂから通信部１０４を介して被写体Ｌｉｓｔが入力されると、写真データセットを生成し、ＳＮＳ写真データベース１０６へ格納する。承認ユーザのユーザＩＤおよび公開先ユーザのユーザＩＤ以外の初期設定は、実施の形態１と同様に行われる。公開写真管理部１０３ｃは、被写体Ｌｉｓｔのユーザ名を用いて複数の連絡先情報から承認ユーザのユーザＩＤを取得し、写真データセットに記憶する。公開写真管理部１０３ｃは、公開先ユーザのユーザＩＤとして、友達一覧から承認ユーザを除いた範囲のＳＮＳユーザのユーザＩＤを設定する。
　４．２．３　被写体照合部１０９ａ
　被写体照合部１０９ａは、実施の形態２の被写体照合部１０９の被写体照合処理に代えて、以下の被写体照合処理を実行する。実施の形態２では、被写体照合部１０９は、承認ユーザＬｉｓｔを連絡先抽出部１０１ｂへ出力していた。本実施の形態では、被写体照合部１０９ａにより照合されたＳＮＳユーザを、被写体の候補として公開元ユーザへ確認するため、承認ユーザＬｉｓｔに代えて候補Ｌｉｓｔを生成する。
　以下で、被写体照合処理について、図２６に示すフローチャートを用いて説明する。
　被写体照合部１０９ａは、特徴量抽出部１０８から入力された被写体の顔の画像の特徴量から、検出した被写体の人数を抽出する（Ｓ２１０１）。被写体照合部１０９ａは、照合する動作回数をｃとし、初期値に０を設定する（Ｓ２１０２）。
　被写体照合部１０９ａは、現在の照合対象の被写体について、特徴量抽出部１０８から入力された被写体の顔の画像の特徴量を、ＳＮＳユーザデータベース１０５ａ内の複数の顔の画像の特徴量と照合しマッチングを行う（Ｓ２１０３）。被写体照合部１０９ａは、照合対象の被写体について、顔の画像の特徴量が一致するデータを有するＳＮＳユーザデータが存在するか否かを確認する（Ｓ２１０４）。照合は、ＳＮＳユーザおよび被写体ユーザの両方の顔の特徴量に対して行う。
　被写体照合部１０９ａは、ステップＳ２１０４において、一致するＳＮＳユーザデータがあれば（Ｓ２１０４のＹ）、顔の画像の特徴量が一致したユーザのユーザ名を候補Ｌｉｓｔに記憶する（Ｓ３１０１）。顔の画像の特徴量が一致したユーザが被代理ユーザではない場合は、ＳＮＳユーザ本人のユーザ名が記憶される。顔の画像の特徴量が一致したユーザが被代理ユーザである場合は、当該被代理ユーザのユーザ名が記憶される。
　被写体照合部１０９ａは、ステップＳ２１０４において、一致するＳＮＳユーザデータがない場合は（Ｓ２１０４のＮ）、ステップＳ２１０５を実行せず、ステップＳ２１０６に移行する。
　被写体照合部１０９ａは、被写体を照合する動作回数ｃをインクリメントする（Ｓ２１０６）。被写体照合部１０９ａは、照合する動作回数ｃが抽出した被写体の人数に達したか否かを確認する（Ｓ２１０７）。被写体照合部１０９ａは、照合する動作回数ｃが被写体の人数に達していない場合（Ｓ２１０７のＮ）、被写体の顔の画像の特徴量を、ＳＮＳユーザデータベース１０５ａ内のユーザの顔の画像の特徴量と照合しマッチングを行う（Ｓ２１０３）。
　被写体照合部１０９ａは、被写体の人数分だけＳ２１０３～Ｓ２１０６の処理を繰り返す。
　被写体照合部１０９ａは、ステップＳ２１０７において、照合する動作回数ｃが被写体の人数に達している場合（Ｓ２１０７のＹ）、候補Ｌｉｓｔが空であるか否かを確認する（Ｓ２１０８）。被写体照合部１０９ａは、候補Ｌｉｓｔが空でなかった場合（Ｓ２１０８のＮ）、候補Ｌｉｓｔを候補提示部１１０へ出力する（Ｓ３１０２）。被写体照合部１０９は、さらに、候補Ｌｉｓｔが空であった場合（Ｓ２１０８のＹ）、被写体照合部１０９ａは、該当ユーザなしの結果を通信部１０４へ出力し、公開元ユーザへ送信する（Ｓ２１１１）。
　４．２．４　候補提示部１１０
　候補提示部１１０は、被写体照合部１０９ａから入力された候補Ｌｉｓｔを、通信部１０４を介して携帯端末２００ｂへ出力する。また、候補提示部１１０は、候補Ｌｉｓｔを送信する。サーバは、携帯端末２００ｂから通信部１０４を介して被写体Ｌｉｓｔを受け付け、当該被写体Ｌｉｓｔを連絡先抽出部１０１ｂへ出力する。
　候補Ｌｉｓｔの構成を図２３に示す。図２３に示すように、候補Ｌｉｓｔは、該当ユーザの人数と被写体の候補のユーザ名とを含む。該当ユーザの人数は、初期値はゼロであり、候補が抽出された場合に、人数が設定される。
　４．３　携帯端末２００ｂの構成
　図２１は、公開承認依頼システム１０ｂにおける携帯端末２００ｂの構成図である。携帯端末２００ｂは、実施の形態１と同様の写真選択部２０１、入力部２０３、通信部２０４および写真データベース２０５、実施の形態１と異なるユーザ指定部２０２ａ、候補選択部２０６および表示部２０７を備えて構成される。
　４．３．１　ユーザ指定部２０２ａ
　ユーザ指定部２０２ａは、サーバ１００ｂから候補Ｌｉｓｔを受信し、候補選択部２０６において被写体の候補から被写体が選択された後、携帯端末２００ｂのユーザの入力動作の内容を基に、候補Ｌｉｓｔに含まれるＳＮＳユーザ以外のＳＮＳユーザを承認ユーザとして指定する。言い換えると、ユーザ指定部２０２ａは、候補選択部２０６から承認ユーザＬｉｓｔを受け付けた後に、表示部２０７を用いて携帯端末２００ｂの画面に承認ユーザを追加するための画像を表示させる。ユーザ指定部２０２ａは、ユーザの入力動作に応じて、追加の承認ユーザを特定する。なお、被代理ユーザを追加できるようにし、被代理ユーザの承認ユーザを自動的に抽出するように構成してもよい。
　ユーザ指定部２０２ａは、ユーザの入力動作により他の承認ユーザが指定された場合は、候補選択部２０６から出力された被写体Ｌｉｓｔに指定された承認ユーザのユーザ名を追加し、通信部２０４を介してサーバ１００ｂへ出力する。ユーザ指定部２０２ａは、ユーザの入力動作による他の承認ユーザの指定がなければ、候補選択部２０６から出力された被写体Ｌｉｓｔを通信部２０４へ出力する。
　実施の形態１では、ユーザ指定部２０２は、被写体および公開先ユーザの指定を写真データの送信と同時に行っていた。また、実施の形態２では、承認ユーザおよび公開先ユーザはサーバで設定された。本実施の形態では、ユーザ指定部２０２ａは、ユーザの入力動作により特定された候補を承認ユーザとして追加する。
　４．３．２　候補選択部２０６
　候補選択部２０６は、サーバ１００ｂから候補Ｌｉｓｔを受信した際、候補Ｌｉｓｔを写真の公開元ユーザに対し表示部２０７を介して提示する。候補選択部２０６は、公開元ユーザの入力動作により被写体の候補の中から被写体が選択されると、選択された被写体のユーザ名を含む被写体Ｌｉｓｔを生成し、当該被写体Ｌｉｓｔをユーザ指定部２０２ａへ出力する。
　４．３．３　表示部２０７
　表示部２０７は、写真の公開元ユーザへ承認ユーザの候補を提示するために、候補選択部２０６から入力された候補Ｌｉｓｔを携帯端末２００ｂの画面に表示する。
　図２２は、被写体の候補から被写体を選択する際の候補選択画面の一例を示す図である。図２２では、被写体の候補３名の中から、ＡとＢとを承認ユーザとして選択する場合を示している。
　４．４　公開承認依頼システム１０ｂの動作
　公開承認依頼システム１０ｂには、実施の形態１と同様に、写真公開時および写真閲覧時の２つの動作がある。
　写真閲覧時の動作については、実施の形態１と同様の処理であるため、説明を省略し、以下で、写真公開時の動作について、図面を参照しながら説明する。
　公開承認依頼システム１０ｂでは、実施の形態２の被写体検出処理および承認ユーザを設定する処理を次のように変形している。被写体検出処理の変形処理では、公開承認依頼システム１０ｂは、サーバ１００ｂが受信した写真データから被写体を検出し、検出した被写体を公開元ユーザの携帯端末２００ｂへ被写体の候補として提示する。携帯端末２００ｂは、提示された候補から選択された被写体のユーザ名を含む被写体Ｌｉｓｔを、サーバ１００ｂへ送信する。承認ユーザを設定する処理の変更処理では、公開承認依頼システム１０ｂは、携帯端末２００ｂから送信された被写体Ｌｉｓｔを用いて、承認ユーザの連絡先を特定する。
　各変形処理の実行箇所は、携帯端末２００からサーバ１００へ写真データを送信する処理（Ｓ１００３）と、特定した承認ユーザの連絡先へ、写真データ、公開元ユーザのユーザ名、公開承認依頼を送信する処理（Ｓ１００６）との間である。
　公開承認依頼システム１０ｂの写真公開時の動作について、図２４、図２５を用いて説明する。図２４および図２５は、写真公開時の動作を示すシーケンス図である。
　公開元ユーザの携帯端末２００ａにより、アップロードする写真を選択する処理（Ｓ１００１）、および、サーバ１００ａへ写真データを送信する処理（Ｓ１００３）が実行される。アップロードする写真を選択する処理、および、サーバ１００ａへ写真データを送信する処理の処理内容は、実施の形態１と同じである。
　サーバ１００ｂは、携帯端末２００ｂから写真データを受信し、被写体照合処理および候補抽出処理を行う（Ｓ３００１）。被写体照合処理は、実施の形態２と同じである。サーバ１００ｂは、本実施の形態では、候補抽出処理で生成した候補Ｌｉｓｔを携帯端末２００ｂへ送信する（Ｓ３００２）。
　携帯端末２００ｂは、サーバ１００ｂから候補Ｌｉｓｔを受信し、画面上に候補を提示して、公開元ユーザに被写体の選択および追加処理のための入力動作を行わせる（Ｓ３００３）。さらに、携帯端末２００ｂは、公開元ユーザの入力動作により特定された被写体のユーザ名を含む被写体Ｌｉｓｔをサーバ１００ｂへ送信する（Ｓ３００４）。
　サーバ１００ｂは、携帯端末２００ｂから被写体Ｌｉｓｔを受信すると、写真データセットを生成し、写真データベースに格納する（Ｓ３００５）。そして、被写体Ｌｉｓｔを用いて承認ユーザの連絡先をＳＮＳユーザデータベース１０５ａから抽出する（Ｓ３００６）。承認ユーザの連絡先の抽出は、具体的には、ＳＮＳユーザデータベース１０５ａから、被写体Ｌｉｓｔに含まれるユーザ名が記憶されたＳＮＳユーザデータを取得する。ＳＮＳユーザデータに代理ユーザの連絡先が含まれる場合は、代理ユーザの連絡先を承認ユーザの連絡先として抽出し、ＳＮＳユーザデータに代理ユーザの連絡先が含まれない場合は、当該ＳＮＳユーザの連絡先を承認ユーザの連絡先として抽出する。サーバ１００ｂは、承認ユーザの携帯端末３００へ写真データ、公開元ユーザのユーザ名、公開承認依頼を送信する（Ｓ１００６）。
　図２５に示すステップＳ１００７～ステップＳ１０１３の処理内容は、実施の形態１と同じである。
　以下で、被写体の選択および追加処理について、図２７を用いて説明する。図２７は、被写体の選択および追加処理を示すフローチャートである。
　携帯端末２００ｂは、サーバ１００から受信した候補Ｌｉｓｔを公開元ユーザに提示し、公開元ユーザの入力動作に基づいて被写体を選択する（Ｓ３２０１）。次に、携帯端末２００ｂは、候補Ｌｉｓｔに含まれるＳＮＳユーザ以外から追加の被写体を設定するか否かを確認する（Ｓ３２０２）。携帯端末２００ｂは、候補Ｌｉｓｔに含まれるＳＮＳユーザ以外から追加の被写体を設定する場合（Ｓ３２０２のＹ）、ユーザの入力動作により指定された被写体を追加の被写体とする（Ｓ３２０３）。携帯端末２００ｂは、候補Ｌｉｓｔに含まれるＳＮＳユーザ以外から追加の被写体を設定しない場合（Ｓ３２０２のＮ）、ステップＳ３２０３を実行せずに被写体の選択および追加処理を終了する。
　４．５　実施の形態４の効果
　本実施の形態では、サーバ１００ｂが検出した被写体の候補を、写真の公開元ユーザの携帯端末へ送信している。さらに、携帯端末２００ａは、写真の公開元ユーザの入力動作により、候補Ｌｉｓｔに含まれるＳＮＳユーザの中から被写体を選択し、サーバ１００ｂへ送信している。
　検出した被写体の候補を公開元ユーザに提示し確認することで、被写体の検出を確実に行うことができる。これにより、より確実に承認ユーザへ公開承認依頼を送信することができる。なお、本実施の形態では、さらに、候補Ｌｉｓｔから候補が選択された後、別途、公開元ユーザが被写体を任意に指定できる。これによって、サーバ１００ｂは、公開元ユーザにより被写体の候補が正しいか否かを確認した上で、承認ユーザを設定できる。例えば、サーバ１００ｂが候補として誤ったユーザを抽出した場合に、公開元ユーザは、誤って抽出された候補を除外し、正しい被写体を追加することができる。さらに、公開元ユーザは、照合処理が正常に終了せず、サーバ１００ｂにより該当ユーザがいないと判断されたユーザを、被写体として追加することが可能になる。
　以上、説明したように、本実施の形態では、より確実に承認ユーザへ公開承認依頼を送信することができ、また、サーバが承認ユーザを正確に判断できなかった場合でも、公開元ユーザが確認し修正できるという効果がある。
　５．実施の形態５
　ここでは、本実施の形態の公開承認依頼システム１０ｃについて図面を参照しながら説明する。実施の形態１～４では、承認ユーザ全員から公開承認依頼に対する回答が揃ってから、公開先ユーザへ写真を公開していた。また、実施の形態１～４では、承認ユーザが回答する機会は一度であった。
　これに対し、本実施の形態では、公開承認依頼に対する回答に期限を設ける。また、回答期限の前後に関わらず、回答の変更を受け付ける。これによって、公開元ユーザは、写真を公開したい時期までに回答を求めることができ、また、承認ユーザは、一度承認とした場合でも、拒否に変更することができる。
　５．１　公開承認依頼システム１０ｃの全体構成
　図２８は、公開承認依頼システム１０ｃの全体構成を示す図である。公開承認依頼システム１０ｃは、実施の形態１と同様の携帯端末３００、携帯端末４００、実施の形態１～４とは異なるサーバ１００ｃ、および、携帯端末２００ｃを備えて構成される。
　５．２　サーバ１００ｃの構成
　図２９は、公開承認依頼システム１０ｃにおけるサーバ１００ｃの構成の一例を示す図である。サーバ１００ｃは、実施の形態１と同様の通信部１０４およびＳＮＳユーザデータベース１０５、実施の形態１と異なる連絡先抽出部１０１ｃ、回答集計部１０２ｂ、公開写真管理部１０３ｂ、ＳＮＳ写真データベース１０６ａおよび回答期限管理部１１１を備えて構成される。
　５．２．１　ＳＮＳ写真データベース１０６ａ
　ＳＮＳ写真データベース１０６ａは、写真データセットとして、実施の形態１におけるＳＮＳ写真データベース１０６の写真データセットに含まれる各情報に加え、回答期限状況および回答期限を格納する。ＳＮＳ写真データベース１０６ａは、さらに、承認ユーザのユーザＩＤの欄に、実施の形態１と同様の個別回答状況ｒｅｓ（図６Ａ参照）に加え、回答を付加する。また、ＳＮＳ写真データベース１０６ａは、実施の形態１での参照の目的に加え、承認ユーザから回答があった際および回答期限を確認する際、回答期限を確認するために参照される。
　５．２．２　連絡先抽出部１０１ｃ
　連絡先抽出部１０１ｃは、通信部１０４から入力された被写体名を受け付け、当該被写体名を用いて承認ユーザの連絡先をＳＮＳユーザデータベースから抽出する。さらに、連絡先抽出部１０１ｃは、抽出した承認ユーザのユーザＩＤと承認ユーザの連絡先とを回答集計部１０２ｂへ出力する。
　５．２．３　回答集計部１０２ｂ
　回答集計部１０２ｂは、携帯端末２００ｃから通信部１０４を介して写真データと回答期限とを受け付け、連絡先抽出部１０１ｃから承認ユーザの連絡先を受け付ける。回答集計部１０２ｂは、承認ユーザの連絡先から特定される携帯端末３００に対し、通信部１０４を介して、写真データ、公開元ユーザのユーザ名、回答期限および公開承認依頼を通信部１０４へ出力する。回答集計部１０２ｂは、同時に、公開写真管理部１０３ｂへ、公開承認依頼を送信した旨を出力する。
　また、回答集計部１０２ｂは、承認ユーザの携帯端末３００から回答を受信した際、通信部１０４から入力された回答を写真データセットへ反映し、写真データセットを更新した旨を公開写真管理部１０３ｂおよび回答期限管理部１１１へ出力する。
　５．２．４　公開写真管理部１０３ｂ
　公開写真管理部１０３ｂは、実施の形態１における公開写真管理部１０３の処理（（１）写真データセットの生成、（２）写真の公開および非公開の判定と、（３）写真の公開）を、以下のように変形する。（２）写真の公開および非公開の判定と、（３）写真の公開とは、実施の形態１と同じである。実施の形態１～４では、回答期限がなかったが、本実施の形態では、回答期限に達したことを確認し、回答期限に達すると、回答が揃わなくても、写真データセットを更新し、公開または非公開を判断する。
　（１）写真データセットの生成
　公開写真管理部１０３は、実施の形態１では、携帯端末２００から写真データ、被写体名、公開先ユーザのユーザ名および公開元ユーザのユーザ名を受信した際に、写真データセットを生成していた。本実施の形態では、公開写真管理部１０３ｂは、写真データ等の受信と同様のタイミングで、回答期限も受信している。よって、携帯端末２００ｃから写真データ、承認ユーザのユーザ名、公開先ユーザのユーザ名および回答期限を受信した際、写真データセットを生成し、ＳＮＳ写真データベース１０６ａに格納する。さらに、公開写真管理部１０３ｂは、回答集計部１０２ｂから受信する回答に応じ、写真データセットを更新する。
　図３１は、ＳＮＳ写真データベース１０６ａ内の写真データセットの構造例を示す図である。
　写真データセットには、実施の形態１と同様の公開元ユーザのユーザＩＤ、写真ＩＤ、公開状況（公開／非公開）、回答状況（承認依頼中／全員回答済）、承認の数、拒否の数、承認ユーザの人数、閲覧可能ユーザＬｉｓｔおよび写真データが含まれる。さらに、本実施の形態の写真データセットには、実施の形態１と異なる承認ユーザのユーザＩＤ、回答期限状況（期限前／期限後）および回答期限が含まれる。承認ユーザのユーザＩＤには、実施の形態１のユーザＩＤおよび個別回答状況（未回答／回答済）に加え、回答（承認／拒否）を付加する。
　写真データセット生成時の初期値は、それぞれ、公開状況は「非回答」、承認の数ｏｋ＿ｎｏはゼロ、拒否の数ｎｇ＿ｎｏはゼロ、回答状況ａｎｓ＿ｓｔａｔｕｓは「期限前」、回答期限ｄｕｅ＿ｄａｔａは公開元ユーザが指定した回答期限、個別公開状況ｒｅｓは「未公開」、回答ａｎｓは「拒否」と設定する。回答期限状況ｄｅａｄｌｉｎｅは設定しない。
　公開写真管理部１０３ｂは、回答集計部１０２ｂから、公開承認依頼を送信した旨を入力されると、実施の形態１と同様に、写真データセット内の回答状況ａｎｓ＿ｓｔａｔｕｓに「承認依頼中」を設定する。
　公開写真管理部１０３ｂは、回答集計部１０２ｂから写真データセットを更新した旨を入力されると、回答の回答期限をＳＮＳ写真データベース１０６ａ内の写真データセットから確認する。
　公開写真管理部１０３ｂは、回答集計部１０２ｂから写真データセットを更新した旨を入力されると、回答期限状況と回答とを確認する。公開写真管理部１０３ｂは、回答期限状況が「期限後」であるときに、公開状況が「公開」である写真について拒否の回答がきた場合、写真データセット内の公開状況を「非公開」に変更し、公開先ユーザへの公開を中止する。
　（２）写真の公開および非公開の判定
　公開写真管理部１０３ｂは、写真ＩＤと回答期限が来た旨とを回答期限管理部１１１から受信した場合は、当該写真ＩＤの写真データセット内の回答期限状況を「期限後」に設定する。さらに、公開写真管理部１０３ｂは、回答期限までに回答がなかった承認ユーザの回答を「承認」に設定する。
　その後、公開写真管理部１０３ｂは、拒否の数ｎｇ＿ｎｏを確認し、拒否が一人もいない場合（拒否の数ｎｇ＿ｎｏがゼロの場合）、写真データセットの公開状況ｓｔａｔｕｓを「非公開」から「公開」に変更し、公開先ユーザへも写真を公開する。
　公開写真管理部１０３ｂは、拒否が一人でもいる場合は、公開状況は「非公開」のままとし、公開先ユーザへは写真を公開しない。
　５．２．５　回答期限管理部１１１
　回答期限管理部１１１は、ＳＮＳ写真データベース１０６ａ内に写真データセットが生成されたときに写真データセット内の回答期限を定期的に確認し、回答期限に達したか否かを判断する。回答期限管理部１１１は、回答期限に達したときに、公開写真管理部１０３ｂへ写真ＩＤと回答期限がきた旨とを出力する。
　なお、回答期限管理部１１１は、公開写真管理部１０３ｂから回答期限の確認が依頼された際に、回答期限の確認を行うように構成してもよい。この場合において、公開写真管理部１０３ｂは、例えば、回答集計部１０２ｂが公開承認依頼に対する回答を受信するたびに、回答期限の確認の依頼を行ってもよい。
　５．３　携帯端末２００ｃの構成
　図３０は、公開承認依頼システム１０ｃにおける携帯端末２００ｃの構成図である。携帯端末２００ｃは、実施の形態１と同様の写真選択部２０１、ユーザ指定部２０２、入力部２０３、通信部２０４、および、写真データベース２０５に加え、回答期限設定部２０８を備えて構成される。
　５．３．１　回答期限設定部２０８
　回答期限設定部２０８は、写真の公開元ユーザの入力動作によって、公開承認依頼への回答期限を設定する。
　回答期限設定部２０８は、写真選択部２０１から入力された写真データ、ユーザから入力された被写体名および公開先ユーザのユーザ名、設定した回答期限を通信部２０４へ出力する。
　図４４は、公開元ユーザの携帯端末２００ｃの画面に表示される回答期限設定画面の一例を示す図である。図４６は、承認ユーザの携帯端末３００の画面に表示される公開承認依頼受信画面の一例を示す図である。
　５．４　公開承認依頼システム１０ｃの動作
　公開承認依頼システム１０ｃには、実施の形態１と同様に、写真公開時および写真閲覧時の２つの動作がある。
　なお、写真閲覧時の動作については、実施の形態１と同様の処理であるため、説明を省略する。以下、写真公開時の動作について、図面を参照しながら説明する。
　公開承認依頼システム１０ｃの写真公開時の動作は、実施の形態１における公開承認依頼システム１０の動作に、回答期限に関する動作を加えたものとなっている。つまり、公開承認依頼システム１０ｃは、公開承認依頼システム１０の公開承認依頼を行う処理に加え、公開承認依頼の回答期限に達したか否かを確認する処理を行う。
　より詳細には、本実施の形態の携帯端末２００ｃは、実施の形態１の各処理に加え、写真の公開元ユーザによる入力動作に基づいて回答期限を設定する処理、および、回答期限をサーバへ送信する処理を実行する。さらに、本実施の形態のサーバ１００ｃは、回答期限を保存する処理、回答期限を確認する処理、期限後の最初の回答集計処理および期限後の回答変更処理を実行する。
　上述した各処理の実行箇所は、次の２箇所である。携帯端末２００ｃにおける公開元ユーザの入力動作により回答期限を設定する処理および回答期限をサーバへ送信する処理、サーバ１００ｃにおける写真データセットを生成し格納する処理の実行箇所は、携帯端末２００ｃが被写体を指定する処理（Ｓ１００２）とサーバ１００ｃが指定された被写体の情報を用いて、承認ユーザの連絡先をＳＮＳユーザデータベースから抽出する処理（Ｓ１００５）との間である。また、サーバ１００ｃにおける回答期限を定期的に確認する処理、回答期限状況を変更する処理および期限後回答集計処理の実行箇所は、サーバ１００ｃの回答集計処理（Ｓ１００９）と公開状況が「公開」であるか否かを確認する処理（Ｓ１０１１）との間である。
　本実施の形態の公開承認依頼システム１０ｃの動作について、図３２～図３７に示すシーケンス図を用いて説明する。図３２および図３３は、回答集計処理の動作を示すフローチャートである。図３４～図３７は、回答期限の設定に関する動作を示すシーケンス図である。
　図３４に示すように、公開元ユーザの携帯端末２００ａにより、アップロードする写真を選択する処理（Ｓ１００１）、および、被写体および公開先ユーザを指定する処理（Ｓ１００２）が実行される。アップロードする写真を選択する処理、および、被写体および公開先ユーザを指定する処理の処理内容は、実施の形態１と同じである。
　次に、公開元ユーザの携帯端末２００ｃは、回答期限を設定する（Ｓ４００１）。本実施の形態では、例えば、公開元ユーザの入力動作により、回答期限として、１週間後の日付が入力された場合、当該１週間後の日付を設定する。携帯端末２００ｃは、写真データ、承認ユーザのユーザ名、公開先ユーザのユーザ名および回答期限をサーバ１００ｃへ送信する（Ｓ４００２）。
　サーバ１００ｃは、携帯端末２００ｃから写真データ、被写体名、公開先ユーザのユーザ名、および回答期限を受信すると、写真データセットを生成し、ＳＮＳ写真データベースに格納する（Ｓ４００３）。写真データセットの生成時は、実施の形態１の写真データセットの生成と同様の設定に加え、回答期限状況に「期限前」を、回答期限に携帯端末２００ｃから受信した回答期限を設定する。そして、指定された被写体名が記憶されたＳＮＳユーザデータをＳＮＳユーザデータベースから抽出し、抽出したＳＮＳユーザデータに記憶された承認ユーザの連絡先を取得する（Ｓ１００５）。なお、被写体が被代理ユーザの場合は、代理ユーザの連絡先を承認ユーザの連絡先として取得し、被写体が被代理ユーザではない場合は、被写体の連絡先を承認ユーザの連絡先として取得する。さらに、サーバ１００ｃは、抽出した承認ユーザの連絡先に対し、写真データ、公開元ユーザのユーザ名および公開承認依頼を携帯端末３００に送信する（Ｓ１００６）。
　図３５に示すように、サーバ１００ｃは、回答期限に達するまでは（Ｓ４００４のＮ）、承認ユーザの携帯端末３００から回答が入力される度に、回答期限前の回答集計処理を行う（Ｓ１００９）。回答期限前の回答集計処理の詳細については、後述する。回答期限に達した場合（Ｓ４００４のＹ）、ＳＮＳ写真データベース内の写真データセットの回答期限状況を「期限前」から「期限後」に変更する（Ｓ４００５）。なお、期限の確認は、例えば、回答集計処理（Ｓ１００９）の前等、他のタイミングで行ってもよい。
　回答期限状況の変更後、サーバ１００ｃは、回答期限後の回答集計処理を行う（Ｓ４００６）。
　以下で、サーバ１００ｃが行う回答期限後の回答集計処理の詳細について、図３６に示すフローチャートを用いて説明する。
　サーバ１００ｃは、写真データセット内の回答状況が「未回答」のユーザの個別回答状況、回答をそれぞれ「回答済」、「承認」に設定する（Ｓ４１０１）。サーバ１００ｃは、写真データセット内の承認の数をインクリメントし、写真データセットを更新する（Ｓ４１０２）。サーバ１００ｃは、写真データセット内の回答状況を「承認依頼中」から「全員回答済」に変更する（Ｓ４１０３）。サーバ１００ｃは、拒否の数がゼロか否かを確認する（Ｓ４１０４）。サーバ１００ｃは、拒否の数がゼロであれば（Ｓ４１０４のＹ）、写真データセットの公開状況を「非公開」から「公開」に変更する（Ｓ４１０５）。サーバ１００ｃは、拒否の数が１以上であれば（Ｓ４１０４のＮ）、公開状況は変更せず終了する。
　図３５に示すステップＳ１０１０～ステップＳ１０１３の処理内容は、実施の形態１と同じである。
　引き続き、承認ユーザが、回答期限後、携帯端末３００のユーザ以外のユーザへ写真が公開された後に、公開承認依頼の回答をするまたは回答を変更する場合の公開承認依頼システム１０ｃの動作について、図３７を用いて説明する。図３７は、回答期限後の公開承認依頼の回答に対する処理（つまり、公開および非公開の判定の変更処理）を説明するためのシーケンス図である。なお、回答期限後に公開承認依頼の回答をする動作と、回答を変更する動作は同じである。前者は、回答期限後の時点で「承認」とみなされており、後者は、「承認」または「拒否」を選択されており、共に回答が写真データセットに反映されている。また、回答期限後に「承認」の回答があった場合は、公開および非公開の判定が変更されないため、図３７では、回答期限に達した直後の公開状況が「公開」であり、回答期限後に「拒否」の回答があった場合について示している。
　図３７に示すように、サーバ１００ｃは、回答期限後、公開先ユーザへ写真データセットを公開する（Ｓ１０１３）。
　承認ユーザの携帯端末３００は、承認ユーザの入力動作により、携帯端末３００のユーザ以外のユーザへの公開についての回答あるいは回答の変更を受け付ける（Ｓ５００１）。ここでは、上述したように、「拒否」が選択される。携帯端末３００は、ユーザＩＤと回答（「拒否」）とをサーバ１００ｃへ送信する（Ｓ５００２）。
　サーバ１００ｃは、承認ユーザから期限後の回答あるいは回答の変更を受信すると、写真データセットの回答変更処理を行う（Ｓ５００３）。サーバ１００ｃは、ここでは、写真データセットの複数の個別回答状況の１つが、承認から拒否に変更されるため、写真データセットの公開状況を「非公開」に変更する。サーバ１００ｃは、公開先ユーザへの写真の公開を中止する（Ｓ５００４）。
　以下で、サーバ１００ｃが行う写真データセット回答変更処理の詳細について、図３８に示すフローチャートを用いて説明する。
　サーバ１００ｃは、携帯端末３００から受信したユーザＩＤが承認ユーザに含まれるか否かを確認する（Ｓ５１０１）。サーバ１００ｃは、携帯端末３００から受信したユーザＩＤが承認ユーザに含まれなければ（Ｓ５１０１のＮ）、回答集計処理を終了する。サーバ１００ｃは、携帯端末３００から受信したユーザＩＤが承認ユーザに含まれれば（Ｓ５１０１のＹ）、写真データセット内の公開状況を「公開」から「非公開」に変更する（Ｓ５１０２）。公開元ユーザへ、更新結果として写真公開を中止した旨を送信する（Ｓ５１０３）。
　一方、ステップＳ５００３において、携帯端末３００から、拒否から承認への変更を受け付けた場合において、全ての承認ユーザの回答が承認となったときは、サーバ１００ｃは、写真データセット内の公開状況を「非公開」から「公開」に変更する。
　５．４．１　回答集計処理
　公開承認依頼システム１０ｃの回答集計処理の動作について、図３２、図３３に示すフローチャートを用いて説明する。
　当該回答集計処理では、公開承認依頼システム１０ｃは、実施の形態１における処理に、次の処理を加えている。回答期限前に回答された場合の処理として、承認ユーザのユーザＩＤに付加された回答に「承認」または「拒否」を代入する処理を加えている。また、回答期限前に回答が変更された場合の処理として、前の回答の数をデクリメントし、新しい回答の数をインクリメントする処理を加えている。
　上述した３つの処理の実行箇所は、承認ユーザのユーザＩＤに付加された個別回答状況を確認する処理（Ｓ１１０２）と、承認の数と拒否の数が承認ユーザの人数と等しいかを確認する処理（Ｓ１１０５）との間である。
　サーバ１００ｃは、実施の形態１と同様に、携帯端末３００から公開承認依頼への回答とユーザＩＤを受信すると、受信したユーザＩＤが承認ユーザに含まれるか否かを確認する（Ｓ１１０１）。サーバ１００は、受信したユーザＩＤが承認ユーザに含まれなければ（Ｓ１１０１のＮ）、回答集計処理を終了する。サーバ１００は、受信したユーザＩＤが承認ユーザに含まれれば（Ｓ１１０１のＹ）、当該ユーザＩＤの個別回答状況が「未回答」であるか否かを確認する（Ｓ１１０２）。なお、ステップＳ１１０２の個別回答状況の確認において、個別回答状況が「未回答」の場合（Ｓ１１０２のＹ）は、回答期限前に回答をする場合に相当し、個別回答状況が「回答済」の場合（Ｓ１１０２のＮ）は、回答期限前に回答を変更する場合に相当する。
　サーバ１００ｃは、本実施の形態では、ステップＳ１１０２において、個別回答状況が「未回答」の場合（Ｓ１１０２のＹ）、承認ユーザのユーザＩＤに付加された個別回答状況を「回答済」に変更する（Ｓ１１０３）。そして、サーバ１００ｃは、承認ユーザのユーザＩＤに付加された回答に回答（承認／拒否）を設定する（Ｓ４１０１）。サーバ１００ｃは、回答に基づき、承認の数または拒否の数をインクリメントし、写真データセットを更新する（Ｓ１１０４）。
　一方、個別回答状況が「回答済」の場合（Ｓ１１０２のＮ）、サーバ１００ｃは、前の回答の数をデクリメントし、新しい回答の数をインクリメントする（Ｓ４１０２）。例えば、前の回答が「承認」、新しい回答が「拒否」であるとき、承認の数ｏｋ＿ｎｏをデクリメントし、拒否の数ｎｇ＿ｎｏをインクリメントする。前の回答が「拒否」、新しい回答が「承認」であるとき、拒否の数ｎｇ＿ｎｏをデクリメントし、承認の数ｏｋ＿ｎｏをインクリメントする。
　そして、サーバ１００ｃは、承認の数と拒否の数の合計を出し、承認ユーザの人数と等しいかを確認する（Ｓ１１０５）。
　５．５　実施の形態５の効果
　実施の形態５では、写真の公開元ユーザが、回答期限を設定し、サーバが、回答期限を管理している。このように、回答期限を設定できれば、回答を無期限に待つのではなく、公開したい時期までに回答を求めることができる。
　なお、回答期限までに回答できない承認ユーザがいた場合、回答をしていない承認ユーザがいる状態で、公開先ユーザへも写真を公開することになる。このとき、公開先ユーザへも写真を公開した後、承認ユーザが公開承認依頼に回答をすることも想定される。そこで、回答期限後も、承認ユーザが回答をすることができ、サーバで回答を反映できるようにすることで、回答期限後に拒否の回答をした場合でも、写真の公開を中止し回答を反映することができるようになる。
　また、承認ユーザが、一度は承認の回答をしたが、後から拒否の回答をすることも想定される。そこで、回答期限後に回答をすることが可能になることに加え、承認後も回答を受け付けるようにすることで、承認の回答を得て写真が公開先ユーザへも公開された後でも、写真の公開を中止できるようになる。
　以上、説明したように、実施の形態５では、承認ユーザからの公開承認依頼への回答をより効率よく行い、回答を無期限に待つことなく公開先ユーザへも公開することができるという効果がある。また、一方で、回答期限後や公開先ユーザへの公開後でも、承認ユーザの意見が反映され公開を中止できるという効果がある。
　６．その他の変形例
　なお、本発明を上記各実施の形態に基づいて説明してきたが、本発明は、上記各実施の形態に限定されないのはもちろんである。以下のような場合も本発明に含まれる。
　（１）実施の形態１～４では、全員から承認を得られた場合にのみ公開先ユーザへも公開しているが、公開先ユーザをいくつかのグループに分け、サーバが自動的に時間をずらして段階的に公開してもよい。例えば、公開元ユーザと承認ユーザとの共通の友達を第一のグループ、公開元ユーザの投稿へ頻繁にコメントをくれる友達を第二のグループ、公開元ユーザの友達を第三のグループ、それ以外を第四のグループとした場合、第一のグループは公開元ユーザが写真をアップロードした直後、第二のグループは１日後、第三のグループは２日後、第四のグループは３日後にそれぞれ公開する。これにより、例えば、第一のグループに公開した後すぐ、第一のグループ内の友達から、間違った写真を公開しているとコメントをもらえば、第二のグループに公開する前にその写真を差し替えることができる。また、写真公開が好ましくないというコメントをもらえば、第二のグループ以降への公開を中止することができる。また、グループごとに公開する内容を変えてもよい。例えば、第一のグループにはＧＰＳ情報付きの写真を公開し、第四のグループにはＧＰＳ情報の付いていない写真公開してもよい。
　（２）実施の形態２～４では、サーバが、友達一覧を用いて公開先ユーザを設定しているが、これに限るものではない。
　実施の形態１と同様に、写真データごとに、公開元ユーザが、公開先ユーザの設定を変更（追加および削除）してもよい。例えば、サーバにより設定された公開元ユーザの友達一覧の範囲を、承認ユーザと公開元ユーザの共通の友達の範囲に変更してもよい。この場合、公開元ユーザは、公開元ユーザの友達一覧に含まれるＳＮＳユーザから、承認ユーザとの共通の友人以外のＳＮＳユーザを削除する。これにより、公開元ユーザは、各写真に合わせて柔軟に公開先ユーザを設定することができる。
　（３）実施の形態２～４では、サーバにより、公開先ユーザとして、友達一覧から承認ユーザおよび被代理ユーザを除いた範囲を設定されているが、これに限るものでなはい。
　例えば、友人を親密度によりいくつかのグループに分け、これらのグループの一覧を用いて公開先ユーザを設定してもよい。親密度とは、ユーザ同士の親しさの度合いであり親しいほど高い。また、公開先ユーザの決定に、写真の分類を用いてもよい。写真の分類とは、写真を撮った場面や状況による写真の分類である。例えば、背景のみが写った写真、写真の中に、自転車や車など趣味に関する写真などである。写真の分類に加え、共通の話題を持っているユーザを識別して、公開先ユーザを設定してもよい。例えば、海の写真の場合、海が好きであるというプロフィールのあるユーザや海に関するコミュニティに属しているユーザを公開先ユーザに設定する。これにより、写真を撮った場面や状況、ユーザ同士の関係を考慮し、写真ごとの公開ができる。
　（４）実施の形態１～５では、公開元ユーザが指定する写真を１枚ずつ公開しているが、複数枚を一つのアルバムとして公開承認依頼を送信してもよい。これにより、１枚ずつ公開承認依頼を送信する手間がなく、公開先ユーザへも公開することについて、承認ユーザに確認が取れる。また、元のアルバムから承認された写真だけを抜粋し、アルバムを再編成し公開することができる。
　（５）実施の形態１～５では、承認ユーザ全員の承認を得た場合のみ、公開先ユーザへも写真を公開しているが、しきい値を設定し、しきい値以上の承認が得られた場合に公開先ユーザへも公開するようにしてもよい。例えば、しきい値を３とし、承認の数が３以上であれば公開先ユーザへも公開する。また、全員が回答を送信していなくても、承認の数がしきい値以上になった時点で公開先ユーザへも公開してもよい。また、逆に、拒否の数をしきい値として設定してもよい。これにより、全員の回答を待たなくても公開先ユーザへ写真を公開するか否かを判断することができる。しきい値の設定は、公開承認依頼システム全体で決めてもよい。また、公開元ユーザと承認ユーザの間で決めても、公開元ユーザのみが決めてもよい。
　（６）上記変形例（５）では、しきい値となる承認の数を設定し、しきい値以上の承認が得られた場合に公開先ユーザへも公開しているが、各承認ユーザの回答に対し重みを付けた値を計算し、所定のしきい値に達した場合に公開先ユーザへも公開するようにしてもよい。例えば、承認を＋１、拒否を－１とし、上記変形例（３）における親密度の低いユーザは×３、それ以外は×１として値を計算する。このとき、所定の重み付承認累計を設定した場合、計算した値が、所定の重み付承認累計を上回れば公開と判断する。一方、所定の重み付拒否累計を設定した場合、計算した値が、所定の重み付拒否累計を下回れば非公開と判断する。これにより、一人でも拒否がいると公開できないという設定よりも柔軟に、公開先ユーザへの公開ができる。
　（７）実施の形態１～５では、承認ユーザの回答集計結果として、当該写真を公開したのか非公開としたのかという結果を公開元ユーザへ送信しているが、さらに、各承認ユーザから、回答と共に、公開に当たってのコメントをもらい、それを承認ユーザの承諾の下、公開元ユーザにフィードバックとして送信してもよい。承認ユーザへは、コメントをフィードバックとして送信してもよいか、ユーザ名を開示してもよいかという承諾を求める。例えば、実施の形態１では、承認ユーザには公開先ユーザのユーザ名が開示されていないため、承認ユーザは、共通の友達の範囲であれば、写真を公開してもよいというコメントをする。そのフィードバックが公開元ユーザに送信され、コメントに応じて当該写真の公開先を変更することができる。また、承認ユーザが拒否の回答を開示することを承諾した場合、公開元ユーザが、拒否の回答をした承認ユーザを把握できるため、拒否の回答をした承認ユーザの写っている部分を加工することもできる。拒否の回答をした承認ユーザの写っていない写真のみを選択し、公開先ユーザへも公開することもできる。
　（８）実施の形態１～５で承認ユーザへ公開承認依頼を送信しているが、公開承認依頼を受信した際の通知方法として、承認ユーザにＳＮＳ上でポップアップを表示してもよい。また、ＳＮＳユーザデータベースにメールアドレスを記憶し、メールを送信するとしてもよい。これにより、公開承認依頼を受信したことを知らせる方法として、複数の手段で通知することができる。
　（９）実施の形態５で承認ユーザへ回答期限を設定して公開承認依頼を送信しているが、承認ユーザへは、回答期限の残り時間または残りの日数を表示してもよい。例えば、承認ユーザのＳＮＳのログイン後のホーム画面上に、公開承認依頼の回答期限のスペースを設け、「回答期限（１／１）まであと３日」のように表示する。これにより、回答期限を通知するだけでなく、回答期限までのカウントダウンなども可視化でき、承認ユーザが期限を意識しやすくなる。また、複数の写真について公開承認依頼が来ている場合、カレンダーのようなスケジュールを表示し、各写真の回答期限を記載してもよい。回答期限のカレンダー表示例を図４８に示す。これは、ユーザＸのＳＮＳのホーム画面上にカレンダーがある図である。今日が１月１日であり、写真Ａの回答期限が１月８日、写真Ｂの回答期限が１月１７日、写真Ｃの回答期限が１月３０日であることを表示している。これにより、公開承認依頼の件数や各公開承認依頼の回答期限が、一目で確認できるようになる。
　（１０）実施の形態５で公開元ユーザが回答期限を設定しているが、回答期限の最短の値をシステムで設定しておき、サーバが設定された回答期限を判定するとしてもよい。例えば、回答期限を最短で依頼後３日や１週間のように設定し、回答可能な期間を設けておく。これにより、少なくとも公開されない期間があるため、承認ユーザが写真を確認する時間に余裕ができるよう配慮することができる。
　（１１）実施の形態５で承認ユーザが拒否の回答をした場合、サーバ１００ｃでは、写真データセット内の公開状況を「公開」から「非公開」にする処理を実行するが、写真データセット内のユーザＩＤに付加された回答を「承認」から「拒否」に変更する処理を加えてもよい。また、承認の数をデクリメントし、拒否の数をインクリメントしてもよい。これにより、上記変形例（５）のようにしきい値を設定して公開または非公開を判断する際、例えば、公開となった写真に対し、後から拒否の回答が送信され、新しい回答を含めて再度しきい値との比較を行って、公開の継続、公開の中止を判断できる。
　（１２）実施の形態１～４において承認ユーザに公開承認依頼を送信する際、公開先ユーザを含め、公開元ユーザと承認ユーザとで公開先ユーザを決定してもよい。例えば、公開元ユーザＡは、公開先ユーザにＡの友達一覧の範囲を設定し、サーバが承認ユーザＢへ公開承認依頼を送信する。公開承認依頼を受信した承認ユーザＢは、Ａの友達一覧にはＢの知らないユーザもいるため、公開先ユーザをＡとＢの共通の友達の範囲に変えてほしいと指定し、承認の回答を送信する。公開元ユーザＡは、回答を基に公開先ユーザをＡとＢの共通の友達の範囲に決定しその範囲へ写真を公開する。これにより、公開元ユーザと承認ユーザとの合意の下で、公開先ユーザを決定することができる。
　（１３）実施の形態４において、公開元ユーザが送信する承認ユーザに承認ユーザ候補以外のユーザを指定した場合、写真の指定されたユーザの顔から特徴量を抽出し、ＳＮＳユーザデータベースをそのユーザの顔の画像の特徴量として登録してもよい。これにより、アカウント作成時に顔写真を登録していないユーザも、照合するデータベースに顔の画像の特徴量を登録できる。
　（１４）実施の形態２で顔認識をして承認ユーザを決定しているが、照合する際、照合するＳＮＳユーザの顔の画像の特徴量について、友達一覧の範囲とそれ以外とで比較する量を変えてもよい。例えば、被写体の顔の画像の特徴量とユーザの顔の画像の特徴量とを比べる際、友達一覧の範囲のユーザに関しては、比較する特徴量の差分の値を５０と設定しておき、友達以外の範囲のユーザに関しては、比較する特徴量の差分の値を３０と設定しておく。これにより、写真の被写体には友達の方が写っている確率が高いため、友達一覧の範囲で、より効率的に、より適切な承認ユーザを決定することができる。
　（１５）実施の形態１の回答集計処理の際、ユーザＩＤが承認ユーザに含まれなかった場合や個別回答状況が「回答済」の場合、回答集計処理を終了するが、サーバから公開元ユーザの携帯端末へエラーを返してもよい。これにより、例えば、回答を送信したユーザが誤って再度回答を送信した場合でも、ユーザへ回答済みであることをフィードバックできる。
　（１６）実施の形態５で公開元ユーザが回答期限を設定する際、複数の写真を公開したい場合、カレンダーのようなスケジュールを表示し、各写真の回答期限をカレンダー上で指定してもよい。これにより、複数の写真の公開承認依頼の回答期限を一括で指定できる。回答期限をカレンダーで設定する画面表示例を図４９に示す。これは、写真Ａ、写真Ｂ、写真Ｃを一度にアップロードする際、各写真の公開承認依頼に対する回答期限をカレンダーから設定する例である。
　（１７）上記変形例（４）で、写真をアルバムにして公開しているが、その際、アルバム毎に写真データセットを生成してもよい。例えば、アルバムＩＤをもち、各写真の写真ＩＤＬｉｓｔを持たせてもよい。各写真ＩＤの写真データセットの集合がアルバムデータセットのように構成してもよい。これにより、アルバム内の写真毎に、承認ユーザを割り当てることができる。さらに、全ての写真について、共通の公開先ユーザを取り、その共通する公開先ユーザごとの閲覧できる写真のアルバムが作成できる。
　（１８）上記実施の形態１～５では、承認ユーザの端末として、携帯端末３００を例に説明したが、これに限るものではない。承認ユーザの端末は、携帯端末以外の端末であってもよい。同様に、公開元ユーザの端末および公開先ユーザの端末として、携帯端末２００および携帯端末４００を例に説明したが、これに限るものではない。公開元ユーザの端末および公開先ユーザの端末は、携帯端末以外の端末であってもよい。
　（１９）上記実施の形態１～５では、被代理ユーザの場合にのみ、ＳＮＳユーザデータに承認ユーザになり得る代理ユーザの連絡先が記憶される構成としたが、これに限るものではない。
　被代理ユーザではないＳＮＳユーザのＳＮＳユーザデータに代理ユーザの連絡先を記憶するように構成してもよい。この場合、ＳＮＳユーザデータに、被代理ユーザであるか否かを示すフラグを追加してもよい。
　また、代理ユーザの連絡先は、複数記憶できるように構成してもよい。この場合には、複数の代理ユーザについて、承認ユーザとして選択されるべき順序（優先順位）を指定できるように構成してもよい。
　（２０）上記実施の形態２～４では、友達一覧を優先的に照合するように構成しているが、これに限るものではない。例えば、複数の一覧を設定した場合に、各一覧に優先順位（親密度を利用しても可）を設定し、優先順位の高い一覧から順に照合するように構成してもよい。このように構成すれば、照合において一致する可能性の高いＳＮＳユーザほど優先して照合されるので、サーバの負担を減らすことができる。
　（２１）実施の形態５では、実施の形態１の構成に回答期限を設定する構成を付加しているが、実施の形態２～４の構成に、回答期限を設定する構成を付加してもよい。
　（２２）実施の形態５において、例えば、変形例（１９）で述べたように、被代理ユーザ以外のユーザに代理ユーザの連絡先を記憶しておき、承認ユーザ（被代理ユーザ以外のユーザ）から回答期限内に回答が得られなかった場合に、代理ユーザに公開承認依頼を行うように構成してもよい。
　（２３）実施の形態５において、複数の代理ユーザの連絡先が記憶されている場合は（変形例２２の被代理ユーザ以外のユーザに、複数の代理ユーザの連絡先が記憶されている場合を含む）、優先順位を設定しても良い。この場合、サーバは、優先順位に従い、公開承認依頼を送る代理ユーザを決定し、回答期限内に回答が得られない場合に、次の優先順位の代理ユーザに公開承認依頼を行うように構成してもよい。
　図４５Ｃは、複数の代理ユーザを記憶する場合のＳＮＳユーザデータの構造の一例を示している。図４５Ｃでは、特に、被代理ユーザがユーザＩＤを持つ場合、つまり、実施の形態５における被代理ユーザのＳＮＳユーザデータを示している。
　図４５Ｃでは、回答周期（例えば、５日）が設定されている。また、図４５Ｃにおいて、優先度は、ａｄｄ＿ｓｕｂ１が最も高く、ａｄｄ＿ｓｕｂ２～ａｄｄ＿ｓｕｂｎまで順に低くなるように設定されている。
　図４５Ｃの場合、サーバは、先ず、ａｄｄ＿ｓｕｂ１の代理ユーザの連絡先に公開承認依頼を送信する。サーバは、回答周期に設定された日数が経過しても回答が得られない場合は、次の優先度の承認ユーザ、つまり、ａｄｄ＿ｓｕｂ２の代理ユーザの連絡先に公開承認依頼を送信する。同様に、サーバは、回答周期に設定された日数が経過する毎に、回答が得られているか否かを判定し、回答が得られていない場合は、次の優先順位の承認ユーザの連絡先に公開承認依頼を送信する。サーバは、ａｄｄ＿ｓｕｂｎの代理ユーザまで公開承認依頼を送信しても回答が得られない場合は、回答の設定を「承認」に設定する。
　図４５Ｄは、複数の代理ユーザを記憶する場合のＳＮＳユーザデータの構造の他の一例を示している。図４５Ｄでは、特に、被代理ユーザがユーザＩＤを持たない場合、つまり、実施の形態２～４に実施の形態５を適用した場合において、被代理ユーザを代理する代理ユーザ（承認ユーザ）のＳＮＳユーザデータを示している。
　図４５Ｄでは、図４５Ｃの場合と同様に、回答周期が設定されている。また、図４５Ｄにおいて、優先度は、図４５Ｃの場合と同様に、ａｄｄ＿ｓｕｂ１が最も高く、ａｄｄ＿ｓｕｂ２～ａｄｄ＿ｓｕｂｎまで順に低くなるように設定されている。
　図４５Ｄの場合、サーバは、先ず、当該ＳＮＳユーザデータのＳＮＳユーザに公開承認依頼を送信する。サーバは、回答周期に設定された日数が経過してもＳＮＳユーザから回答が得られない場合は、ａｄｄ＿ｓｕｂ１の代理ユーザの連絡先に公開承認依頼を送信する。サーバは、回答周期に設定された日数が経過してもａｄｄ＿ｓｕｂ１の代理ユーザから回答が得られない場合は、次の優先度の承認ユーザ、つまり、ａｄｄ＿ｓｕｂ２の代理ユーザの連絡先に公開承認依頼を送信する。同様に、サーバは、回答周期に設定された日数が経過する毎に、回答が得られているか否かを判定し、回答が得られていない場合は、次の優先順位の承認ユーザの連絡先に公開承認依頼を送信する。サーバは、ａｄｄ＿ｓｕｂｎの代理ユーザまで公開承認依頼を送信しても回答が得られない場合は、回答の設定を「承認」に設定する。
　（２４）実施の形態１～５において、代理ユーザの連絡先に、公開承認依頼の代理を行う代理期限等を設定してもよい。代理期限は、例えば、現在から子供が所定の年齢に達したとき（子供の所定年齢、例えば、１８歳の誕生日等）まで、あるいは、入院する予定のＳＮＳユーザの入退院の予定日等、ＳＮＳユーザが公開承認依頼に対する回答を行うことが可能になると予想される日時、または、１週間等の期間が考えられる。また、例えば、実施の形態２～４については、ユーザＩＤを持っていない被代理ユーザがユーザＩＤを取得したときに、自動的に被代理ユーザの公開承認依頼の依頼先を、代理ユーザの連絡先から被代理ユーザの連絡先に変更してもよい。代理期限を設定することで、代理ユーザの指定解除に伴う手間を軽減できる。
　（２５）上記の各装置を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ　Ｓｃａｌｅ　Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。
　また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていてもよいし、一部またはすべてを含むように１チップ化されてもよい。
　また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
　さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　（２６）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
　（２７）本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。
　また、本発明は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ（登録商標）　Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。
　また、本発明は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
　また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記憶しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしてもよい。
　また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
　（２８）上記実施の形態および上記変形例をそれぞれ組み合わせるとしてもよい。
　本発明は、ソーシャルネットワークサービスの提供等を行うサーバに適用できる。
　１０，１０ａ，１０ｂ，１０ｃ，１０ｄ　公開承認依頼システム
　１００，１００ａ，１００ｂ，１００ｃ，１００ｄ　サーバ
　１０１，１０１ａ，１０１ｂ，１０１ｃ　連絡先抽出部
　１０２，１０２ａ，１０２ｂ　回答集計部
　１０３，１０３ａ，１０３ｂ，１０３ｃ　公開写真管理部
　１０４　通信部
　１０５，１０５ａ，１０５ｂ　ＳＮＳユーザデータベース
　１０６，１０６ａ　ＳＮＳ写真データベース
　１０７　被写体検出部
　１０８　特徴量抽出部
　１０９，１０９ａ，１０９ｂ　被写体照合部
　１１０　候補提示部
　１１１　回答期限管理部
　２００，２００ａ，２００ｂ，２００ｃ　携帯端末
　２０１　写真選択部
　２０２，２０２ａ　ユーザ指定部
　２０３　入力部
　２０４　通信部
　２０５　写真データベース
　２０６　候補選択部
　２０７　表示部
　２０８　回答期限設定部
　３００　携帯端末
　３０１　回答生成部
　３０２　入力部
　３０３　通信部
　４００　携帯端末
　４０１　公開写真表示部
　４０２　写真閲覧依頼部
　４０３　通信部
　４０４　表示部
　４０５　入力部
　５００，５０１，５０２，５０３　ネットワーク

Claims (11)

  1. 　コンテンツの公開を行うサーバにおいて実行される公開承認依頼方法であって、
    　前記サーバは、前記コンテンツに含まれる被代理ユーザを特定するための第一被代理人情報と前記被代理ユーザを代理する承認ユーザの連絡先とを対応付けた連絡先情報を含む複数の連絡先情報を有し、
    　前記サーバが、前記被代理ユーザを特定するための第二被代理人情報を取得するステップと、
    　前記サーバが、前記第二被代理人情報と前記第一被代理人情報とを比較して、前記複数の連絡先情報から前記被代理ユーザを代理する前記承認ユーザの連絡先を抽出するステップと、
    　前記サーバが、前記承認ユーザの連絡先に公開承認依頼を送信するステップとを含む
    　公開承認依頼方法。
  2. 　第二被代理人情報を取得するステップでは、前記コンテンツの公開元ユーザの端末から前記第二被代理人情報を受け付ける
    　請求項１記載の公開承認依頼方法。
  3. 　前記第二被代理人情報を取得するステップは、前記コンテンツが画像を含む場合に、前記第二被代理人情報として前記画像から顔の画像の特徴量を抽出するステップを有する
    　請求項１記載の公開承認依頼方法。
  4. 　前記複数の連絡先情報のそれぞれは、前記第一被代理人情報として、前記被代理ユーザの顔の画像の特徴量を含み、
    　前記複数の連絡先情報には、予め優先度が設定され、
    　前記承認ユーザの連絡先を抽出するステップでは、
    　前記複数の連絡先情報のうち優先度の高い連絡先情報から順に、前記第二被代理人情報を取得するステップにおいて抽出された前記顔の画像の特徴量と、前記複数の連絡先情報の前記顔の画像の特徴量のそれぞれと比較することにより、前記承認ユーザの連絡先を抽出する
    　請求項３記載の公開承認依頼方法。
  5. 　さらに、
    　前記サーバが、検出された前記顔の画像の特徴量を用いて前記被代理ユーザの１または複数の候補を取得し、前記コンテンツの公開元ユーザの端末に前記１または複数の候補を提示するステップを有する
    　請求項３記載の公開承認依頼方法。
  6. 　さらに、
    　前記サーバが、前記コンテンツの公開元ユーザの端末から前記公開承認依頼の回答期限を取得するステップと、
    　前記サーバが、前記回答期限に基づき、前記回答期限に到達したか否かを判定するステップと、
    　前記サーバが、前記回答期限に達したか否かの判定結果に基づき、公開または非公開を判断するステップとを有する
    　請求項１記載の公開承認依頼方法。
  7. 　前記サーバが、前記公開または非公開を判断するステップにおいて公開と判定されている場合において、前記回答期限に達した後、前記承認ユーザの連絡先から拒否の回答を受信した場合、前記回答に基づき、前記コンテンツの公開を中止する
    　請求項６記載の公開承認依頼方法。
  8. 　前記複数の連絡先情報は、さらに、代理ユーザの連絡先を備え、
    　さらに、
    　前記サーバが、前記回答期限に達したと判定された後に、前記回答が得られていない前記承認ユーザの連絡先情報から、前記代理ユーザの連絡先を抽出し、前記代理ユーザの連絡先に前記公開承認依頼を送信するステップを有する
    　請求項７記載の公開承認依頼方法。
  9. 　前記承認ユーザの連絡先を抽出するステップでは、前記被代理ユーザが複数の場合、前記被代理ユーザのそれぞれについて前記承認ユーザの連絡先を抽出し、
    　さらに、
    　前記サーバが、前記承認ユーザの連絡先のそれぞれから前記公開承認依頼の回答を受信するステップと、
    　前記サーバが、前記回答の承認の数と拒否の数とを集計するステップと、
    　前記サーバが、前記承認の数が所定値以上であれば公開、それ以外であれば非公開と判断するステップとを有する
    　請求項１記載の公開承認依頼方法。
  10. 　コンテンツの公開を行うサーバと、前記公開承認依頼への回答を生成する端末とを含む公開承認依頼システムであって、
    　前記サーバは、
    　前記コンテンツに含まれる被代理ユーザを特定するための第一被代理人情報と前記被代理ユーザを代理する承認ユーザの連絡先とを対応付けた連絡先情報を含む複数の連絡先情報が記憶された記憶部と、
    　前記被代理ユーザを特定するための第二被代理人情報を取得し、前記第二被代理人情報と前記第一被代理人情報とを比較して、前記複数の連絡先情報から前記被代理ユーザを代理する承認ユーザの連絡先を抽出する連絡先抽出部と、
    　前記承認ユーザの連絡先を用いて公開承認依頼を前記端末に送信し、前記端末から前記回答を受信する回答集計部と、
    　回答結果に応じて公開および非公開の判断を行う公開管理部とを備え、
    　前記端末は、
    　前記公開承認依頼について、承認または拒否の回答を生成する回答生成部を備える
    　公開承認依頼システム。
  11. 　コンテンツの公開を行う公開承認依頼サーバであって、
    　前記コンテンツに含まれる被代理ユーザを特定するための第一被代理人情報と前記被代理ユーザを代理する承認ユーザの連絡先とを対応付けた連絡先情報を含む複数の連絡先情報が記憶された記憶部と、
    　前記被代理ユーザを特定するための第二被代理人情報を取得し、前記第二被代理人情報と前記第一被代理人情報とを比較して、前記複数の連絡先情報から前記被代理ユーザを代理する承認ユーザの連絡先を抽出する連絡先抽出部と、
    　前記承認ユーザの連絡先を用いて公開承認依頼を前記端末に送信し、前記端末から前記回答を受信する回答集計部と、
    　回答結果に応じて公開および非公開の判断を行う公開管理部とを備える
    　公開承認依頼サーバ。
PCT/JP2013/006241 2012-11-06 2013-10-22 公開承認依頼方法、公開承認依頼システムおよび公開承認依頼サーバ WO2014073171A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012244791 2012-11-06
JP2012-244791 2012-11-06

Publications (1)

Publication Number Publication Date
WO2014073171A1 true WO2014073171A1 (ja) 2014-05-15

Family

ID=50684297

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/006241 WO2014073171A1 (ja) 2012-11-06 2013-10-22 公開承認依頼方法、公開承認依頼システムおよび公開承認依頼サーバ

Country Status (1)

Country Link
WO (1) WO2014073171A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020086723A (ja) * 2018-11-20 2020-06-04 大日本印刷株式会社 プログラム、情報処理方法、情報処理装置および情報処理システム
JP2020109712A (ja) * 2018-11-20 2020-07-16 大日本印刷株式会社 プログラム、情報処理方法、および情報処理システム
JPWO2020084972A1 (ja) * 2018-10-22 2021-09-16 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 制御方法、コンテンツ管理システム、プログラム、及び、データ構造
JP7108253B1 (ja) 2021-09-28 2022-07-28 ｄｏｕｂｌｅ ｊｕｍｐ．ｔｏｋｙｏ株式会社 情報処理プログラム及び情報処理装置
US11651447B2 (en) 2019-10-31 2023-05-16 Kyndryl, Inc. Ledger-based image distribution permission and obfuscation

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002197186A (ja) * 2000-12-27 2002-07-12 Fujitsu Ltd 個人情報管理装置
JP2009265885A (ja) * 2008-04-24 2009-11-12 Canon Inc オンラインアルバムシステム及びプログラム
WO2011007554A1 (ja) * 2009-07-16 2011-01-20 パナソニック株式会社 アクセス制御装置、アクセス制御方法、プログラム、記録媒体及び集積回路
JP2011077753A (ja) * 2009-09-30 2011-04-14 Fujifilm Corp カメラの顔検出方法及び装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002197186A (ja) * 2000-12-27 2002-07-12 Fujitsu Ltd 個人情報管理装置
JP2009265885A (ja) * 2008-04-24 2009-11-12 Canon Inc オンラインアルバムシステム及びプログラム
WO2011007554A1 (ja) * 2009-07-16 2011-01-20 パナソニック株式会社 アクセス制御装置、アクセス制御方法、プログラム、記録媒体及び集積回路
JP2011077753A (ja) * 2009-09-30 2011-04-14 Fujifilm Corp カメラの顔検出方法及び装置

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2020084972A1 (ja) * 2018-10-22 2021-09-16 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 制御方法、コンテンツ管理システム、プログラム、及び、データ構造
JP7361711B2 (ja) 2018-10-22 2023-10-16 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、コンテンツ管理システム、及び、プログラム
JP2020086723A (ja) * 2018-11-20 2020-06-04 大日本印刷株式会社 プログラム、情報処理方法、情報処理装置および情報処理システム
JP2020109712A (ja) * 2018-11-20 2020-07-16 大日本印刷株式会社 プログラム、情報処理方法、および情報処理システム
US11651447B2 (en) 2019-10-31 2023-05-16 Kyndryl, Inc. Ledger-based image distribution permission and obfuscation
JP7108253B1 (ja) 2021-09-28 2022-07-28 ｄｏｕｂｌｅ ｊｕｍｐ．ｔｏｋｙｏ株式会社 情報処理プログラム及び情報処理装置
WO2023054170A1 (ja) * 2021-09-28 2023-04-06 ｄｏｕｂｌｅ ｊｕｍｐ．ｔｏｋｙｏ株式会社 情報処理プログラム及び情報処理装置
JP2023048197A (ja) * 2021-09-28 2023-04-07 ｄｏｕｂｌｅ ｊｕｍｐ．ｔｏｋｙｏ株式会社 情報処理プログラム及び情報処理装置

Similar Documents

Publication Publication Date Title
US7899887B2 (en) Real time collaborative on-line multimedia albums
JP6311030B2 (ja) 共有仮想空間を生成するためのシステム及び方法
AU2015336948B2 (en) Camera application
CA2799575C (en) Social networking system and method for an online stationery or greeting card service
US20120324002A1 (en) Media Sharing
WO2014073171A1 (ja) 公開承認依頼方法、公開承認依頼システムおよび公開承認依頼サーバ
US20110283172A1 (en) System and method for an online memories and greeting service
WO2016114942A1 (en) Contextual connection invitations
US9405964B1 (en) Processes for generating content sharing recommendations based on image content analysis
US10397322B2 (en) Mobile and computer applications, systems and methods for large group travel and event management
WO2022090841A1 (en) A platform for enabling users for short video creation, publication and advertisement
WO2013028526A1 (en) Method, system, and apparatus for future delivery of digital content over a network
CN105103181A (zh) 人物选择器
US20220122194A1 (en) Method for establishing and maintaining a digital family and friends tree and adding newborn or unborn to same
US10776723B1 (en) Proactive ticket reservation system
JP2020071861A (ja) 情報発信システム及び情報発信プログラム
WO2015061696A1 (en) Social event system
US20190347741A1 (en) System and Method for Facilitating a Life Event Page within a Social Network Application
KR101749603B1 (ko) 사진 정보와 회원 정보를 이용한 통합적 사진 정보 관리 시스템, 사진 관리 방법 및 이를 이용한 사회관계망 서비스 방법
US20190349328A1 (en) System and Method for Managing Prayer Requests within a Social Network Application
US10387974B2 (en) Social networking apparatus and methods
Dimitrov et al. Development of a Mobile Movie Recommendation Application
US20190347742A1 (en) System and Method for Facilitating Church Member Networking within a Social Network Application
US20130013445A1 (en) System and method for producing an album
US20190347361A1 (en) System and Method for Filtering Feeds within a Social Network Application

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13852484

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13852484

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP