JP7615371B2 - System, information processing terminal, method thereof, and operating system. - Google Patents

Description

The present invention relates to technology for providing services using mechanisms such as Web Intents.

Conventionally, when transferring processing between WEB sites, the side calling the function needed to know how to call the function, such as the API (Application Programming Interface) or REST interface of the side providing the function. Therefore, in order to realize cooperation with different websites, the side calling the function needed to process the caller according to the calling conventions of each. Also, in order for the side calling the function to use the function, authentication with the side providing the function is often required. For this reason, the side using the function needed to hold the authentication information of the side providing the function or use an authentication infrastructure such as SAML. However, if authentication information is held, it is necessary to manage the authentication information correctly and securely, and in order to use an authentication infrastructure such as SAML, a prior agreement is required between the provider of the function and the user, which places a burden on the user of the function. Patent Document 1 discloses a technology for using services conventionally provided on the Web.

There are also mechanisms for linking with any web service (or web application) without using a dedicated API. One example is a mechanism called Web Intents, which uses runtime delayed binding to loosely couple service recipients and providers, enabling them to link together.

JP 2009-199369 A

In a new linkage mechanism such as the above-mentioned WebIntents, in order to use the provided functions provided by the service of the mechanism, a user agent (UA) processes an HTML document including markup for registering the function information of the provided function and registers the function information as a Web Intent. The UA can connect to the service using the function information registered in itself and request the execution of the provided function. However, if there are multiple relay functions in an information processing terminal, the function information is registered and managed separately for each relay function. Therefore, even if a certain function information is registered with a certain relay function, the function information cannot be used from another relay function. Therefore, the user must repeatedly register the same function information for each relay function, which is not necessarily convenient. Therefore, it can be said that various improvements to improve usability will be required in the future with regard to requests to services using this Web Intent and registration of WebIntent.

The present invention therefore aims to provide flexible improvements to improve the usability of new collaboration mechanisms, such as currently proposed Web Intents.

The present invention is a system including a server and an information processing terminal, wherein the server has a means for accepting access using a web browser installed on the information processing terminal and a means for providing the web browser with page data including descriptions of a shared object and data to be shared corresponding to the shared object, and the information processing terminal has a means for controlling the display of a selection screen that accepts an operation to select from a plurality of services a service to be used as a sharing destination for the data to be shared corresponding to the shared object on which a user operation has been performed on a page displayed using the web browser based on the page data, and a means for sharing the data to be shared with the sharing destination service selected based on the operation, and is characterized in that on the selection screen, information of the plurality of services as candidate sharing destinations is displayed by an operating system installed on the information processing terminal .

The present invention provides an improvement to improve the usability of new linkage mechanisms such as Web Intents. More specifically, it becomes possible to easily share specific content such as text and images on a page that is in line with the intention of the website providing the page data by selecting a service managed by an OS frequently used by the user of the information processing terminal as the sharing destination in response to a user operation on a shared object on a page displayed on a web browser based on the page data.

FIG. 1 is a diagram illustrating a basic system configuration of Web Intents. FIG. 1 is a sequence diagram illustrating an example of an outline of a basic operation of Web Intents. 1A and 1B are diagrams illustrating examples of Web Intents registration markup and processing requests. An example of a UI for an information processing device with multiple browsers installed. FIG. 1 is a diagram illustrating an example of the hardware configuration of a client and a service 103. FIG. 2 is a diagram illustrating a hardware configuration of an information processing terminal including a UA. FIG. 2 is a diagram illustrating a software configuration of an information processing terminal including a UA. FIG. 4 is a diagram illustrating an example of function information managed by a web browser. FIG. 4 is a sequence diagram of an operation for mutually utilizing function information in the first embodiment. FIG. 4 is a diagram illustrating an example of a screen displayed on a web browser. FIG. 10 is a detailed sequence diagram of a part of the sequence of FIG. 9 . FIG. 10 is a detailed sequence diagram of a part of the sequence of FIG. 9 . FIG. 11 is a diagram illustrating an example of a function information definition file. 11 is a flowchart of a process for mutually utilizing function information in the first embodiment. 11 is a detailed flowchart of a process for acquiring function information by using an intent. FIG. 11 is a sequence diagram of an operation for mutually utilizing function information in the second embodiment. FIG. 17 is a detailed sequence diagram of a part of the sequence of FIG. 16 . 13 is a flowchart of a process for mutually utilizing function information in the second embodiment.

Below, the form for implementing the present invention will be explained with reference to the drawings.

<Basic mechanism of Web Intents>
First, a basic mechanism related to Web Intents, which is an example of a mechanism for linking with an arbitrary Web service (or Web application) without using a dedicated API, will be described with reference to Figures 1 to 3. In the present invention, Web Intents is given as a specific example, but other similar mechanisms can also be applied as a technology for linking with an arbitrary Web service (or Web application).

FIG. 1 is a diagram showing the overall configuration of Web Intents.
In Fig. 1, 103 is a Web Intents service (hereinafter, "service") that provides services and functions using Web Intents technology. 101 is a Web Intents client (hereinafter, "client") that uses the service 103. 106 is a User Agent (hereinafter, "UA") that passes requests from the client 101 to the service 103 and passes results from the service 103 to the client. The UA 106 can be said to have a relay function for executing requests and passing data between the client 101 and the service 103. In addition, Web Intent, which is functional information for calling functions provided by the service 103, is registered in the UA 106.

In this system, for example, client 101 is a website that manages data and has buttons for calling up services, and UA 106 is a web browser that displays the website. Service 103 is a website that is linked to client 101 and that accepts and processes the data managed by client 101 via UA 106.

For example, when this mechanism is applied to a social networking service (SNS), the service 103 becomes a posting service that accepts postings of photos and comments managed by the client and configures a browsing site. If we use the Web Intents mechanism as an example of social buttons such as "Like," "Check," and "Share" on an SNS site, the client 101 becomes the site on which the buttons are located, the UA 106 becomes a web browser, and the service 103 becomes a posting service for "Like" and the like. Note that when user authentication or user operations are required for the service 103 to provide a function, the user performs the operations on the UA 106.

Note that UA106 can be realized by an operating system (OS) or application running on an information processing terminal other than a web browser, so long as it has a function for linking with the services described below. Examples of information processing terminals include personal computers, smartphones, tablet computers, and car navigation devices.

Furthermore, for the service 103, in addition to the service provider on the Internet such as the above-mentioned posting destination service, devices such as a camera, printer, scanner, etc. built into the information processing terminal can also be the service provider. For the service 103, peripheral devices such as a printer, scanner, network camera, etc. connected to a network, and home appliances such as a refrigerator and a television can also be the service provider. Similarly, for the client 101, various devices and applications built into the information processing terminal, other peripheral devices and home appliances on the network, and programs running on them can also be users that call up the service. The client 101, the UA 106, and the service 103 may be any combination of these and run in the same system. Specifically, it is possible that a document editing application having the same function as a web browser operates as a configuration including the client 101 and the UA 106. Also, any of the client 101, the UA 106, and the service 103 may be a function that runs on the same device.

<Web Intents sequence diagram and data example>
FIG. 2 is a sequence diagram for explaining a basic operation related to the provision of a service using Web Intents.

In S201, the UA 106 accesses the service 103 in response to a user operation. In S202, the service 103 returns to the UA 106 an HTML (HyperText Markup Language) response that includes registration markup for having the UA 106 register the functions that the service 103 provides.

Figure 3(a) is a diagram illustrating an example of an HTML document returned from the service 103 to the UA 106 in S202. Below, the contents of the HTML document returned from the service 103 to the UA 106 will be explained using the example of Figure 3(a).

The <intent> tag specifies a function provided by the service 103 and describes function information for calling the function provided by the service 103. The action indicates classification information (category) of the provided function. That is, the action indicates classification information of what function or service the provided function provides. The classification information of the provided function includes, for example, classification information "Share" corresponding to a function for sharing data, classification information "Edit" corresponding to a function for editing data, classification information "View" corresponding to a function for viewing data, classification information "Pick" corresponding to a function for acquiring data, and classification information "Save" corresponding to a function for saving data. That is, the above function information describes classification information such as Share, Edit, View, Pick, or Save.

type indicates the type of data that the provided function can handle. In other words, type indicates the data type that can be handled for action. href indicates the connection destination (URL) of the provided function. title indicates the title of the provided function. Also, disposition indicates how the called provided function is displayed.

In the example of Figure 3 (a), the category of the provided function is "share", the type of data that can be handled is "image data in any format (*)", and the connection destination is "share.html". The title is "Share image using e-mail". Furthermore, it is shown that this function is displayed in a separate window via UA106.

When UA106 receives the HTML response of S202, it asks the user whether or not to register the provided function of service 103 in UA106. For example, if UA106 is a web browser, it displays a pop-up window to prompt the user to select whether or not to register. If the user selects to register this provided function as a web intent, UA106 executes a registration process to internally store the information received in S202. Specifically, the information received in S202 is stored in a storage area of the information processing terminal on which UA106 is running, and is registered in UA106 as web intents.

In S203, UA 106 accesses client 101 through user operation. In S204, client 101 returns to UA 106 an HTML document that describes the use of a function provided by service 103 (Web Intent). For example, when an image and a "Share" button are displayed on a website serving as client 101, the website returns to UA 106 an HTML document that includes ECMAScript as shown in FIG. 3B, which is a Web Intent processing request.

Figure 3(b) is a diagram illustrating an example of an HTML document returned from client 101 to UA 106 in S204. Below, the contents of the HTML document returned from client 101 to UA 106 will be explained using the example of Figure 3(b).

ECMAScript indicates that when the button with the ID "share-photo" in the HTML is clicked, a specified anonymous function is executed. The anonymous function first creates a new Intent object and calls the startActivity() function with this as an argument. When this function is executed, the UA 106 extracts from the Web Intents registered with itself those whose action and type match the specified Web Intent object, and displays a list to request the user to select. The UA 106 also obtains image data held by the client 101 by executing the getImageFrom() function called in the anonymous function.

In S204, UA106 receives the HTML document sent from client 101 and displays a screen based on the HTML document. In S205, when UA106 detects the user pressing the "Share" button on the screen, it executes ECMAScript for activating Web Intents as described above, and in S206, it acquires image data held by client 101. Also, when UA106 detects the pressing of the "Share" button in S205, it displays a list of Web Intents registered in itself. When UA106 detects that the user has selected a Web Intent indicating a function provided by service 103 from this list, it transmits an HTTP request (Web Intent processing request) to service 103 that provides the selected function in S207. At that time, UA106 includes the contents of the Web Intent object created by ECMAScript in FIG. 3(b) in the transmission data.

When the service 103 receives the HTTP request sent from the UA 106 in S207, in S208, it extracts a Web Intent object from the HTTP request and realizes the use of the selected provided function (here, "sharing" image data of the client 101) while interacting with the user via the UA 106.

For example, a user uses a web browser (UA106) to visit a site that has a button for calling up Web Intents for a web storage (client 101) that manages photo data, and presses the button. The web browser (UA106) then displays a pop-up window that includes a list of registered services. If the user selects a web mail function as a service in that pop-up window, a site that provides that function is displayed in a separate window, and as a processing result, a new email with photo data attached is created in that window. This allows the user to send an email.

When the processing related to the provided function is completed, the service 103 returns a response including ECMAScript that notifies the client 101 of the processing result to the UA 106 in S209. When the UA 106 receives the response in S209, it executes the ECMAScript included in the response in S210 and calls the callback function onSuccess() specified by the argument of the startActivity() function in S205. In S211, the UA 106 returns the processing result to the client 101 by the callback function onSuccess().

Through the above processing, the client 101 can call the Web Intents function provided by the service 103 (in this example, "share" an image) via the UA 106.

<Example of UI of information processing terminal in this example>
FIG. 4 is a diagram showing an example of a UI of an information processing terminal according to an embodiment of the present invention.
4, reference numeral 501 denotes an information processing terminal such as a typical mobile terminal or a smartphone. An OS (operating system) such as Android (registered trademark), which is a platform developed targeting mobile information terminals, is installed in the information processing terminal 501.

In the example of FIG. 4, multiple web browsers (browser A, browser B, browser C) are installed as application programs on the information processing terminal 501. Each of these web browsers corresponds to UA 106 in FIG. 1, and each can use Web Intents. In other words, the information processing terminal 501 has multiple Web Intents relay functions.

When a user uses a web browser and finds a service equivalent to 103 in Figure 1, the user registers the service in the web browser as necessary. The list of multiple services managed by a web browser is specific to each web browser. Therefore, the Web Intents registered in a web browser are usually different for each web browser.

In addition, in this embodiment, a smartphone-type information processing terminal as shown in FIG. 4 is used for explanation, but there are no limitations on the type of information processing terminal as a platform, and the present invention can also be applied to general computers (e.g., personal computers).

<Example of Hardware Configuration of Client 101 and Service 103>
FIG. 5 is a block diagram showing an example of the hardware configuration of the client 101 and the service 103 in FIG.
The client 101 and the service 103 can be configured with a general-purpose computer or the like. The client 101 and the service 103 include a CPU 602, a ROM 603, and a RAM 604. The CPU 602 performs overall control of the entire device by reading and executing programs stored in the ROM 603 and a storage device 608 (described later). The ROM 603 is a read-only memory for storing a boot program required for system startup. The RAM 604 is a working memory required when the CPU 602 executes a program.

The network interface (Network I/F) 605 communicates via a network (Network). The display control unit 606 controls the display of the display device 609. For example, the display control unit 606 controls the screen display for managing the Web server, etc. The display device 609 displays the output signal controlled by the display control unit 606 to the operator who is the Web server administrator. The input control unit 607 controls the input signal received from the input devices 610 and 611. The input device 610 is, for example, a pointing device such as a mouse, and the input device 611 is, for example, a keyboard, and receives input from the operator.

The storage device 608 is a non-volatile storage device such as a magnetic disk or flash memory that stores the programs executed by the CPU 602 and various information. In the case of the client 101, the storage device 608 also stores content information provided by the client 101. In the case of the service 103, the storage device 608 also stores data and programs necessary for the service 103 to provide its functions.

The processing of the client 101 and the service 103 shown in this embodiment is realized by the CPU 602 of the client 101 and the service 103 reading and executing the programs stored in the storage device 608.

<Example of Hardware Configuration of Information Processing Terminal 501>
Fig. 6 is a block diagram showing the hardware configuration of the information processing terminal 501, and the UA 106 in Fig. 1 is executed on this hardware. The information processing terminal 501 shown in Fig. 6 is a normal mobile terminal or smartphone, and runs an operating system for small terminals and programs that control calls and data communications.

The hardware components of the information processing terminal 501 are connected to a system bus 801. The ROM 803 stores the operating system of the information processing terminal 501 and applications that control calls and data communications, and is read and executed by the CPU 802. Applications that control data communications include, for example, mail software and a web browser.

RAM 804 is a work memory area for executing programs. RAM 804 also serves as a memory for temporarily storing web page data acquired by the web browser from a web server and authentication information for accessing web services. Storage device 809 is a non-volatile storage device, and stores various operation mode settings and operation logs that need to be retained even after the information processing terminal 501 is restarted.

The network controller 805 controls communication between a wireless LAN communication unit 811 for joining a wireless LAN and a mobile phone data communication unit 812 for joining a network provided by a mobile carrier. In general, when it is possible to join a wireless LAN network, the network controller 805 prioritizes a wireless LAN connection via the wireless LAN communication unit 811. If the information processing terminal 501 leaves the network area of the wireless LAN, the network controller 805 via the mobile phone data communication unit 812 joins the wireless communication network provided by the mobile carrier.

The voice control unit 806 is mainly used when a call application is running and the user is making a call. The microphone/speaker 813 inputs and outputs voice data, and the voice control unit 806 mediates with the control program. The display control unit 807 controls the information output on the display 814 of the information processing terminal 501. The input control unit 808 controls the information specified by the user via the buttons or touch panel 815 of the information processing terminal 501. Using the voice control unit 806, display control unit 807, and input control unit 808, the application on the information processing terminal 501 provides the user with network communication information and various information about the information processing terminal 501. The position detection control unit 810 obtains position information of the information processing terminal 501 from the GPS sensor 816 and provides it to the operating system. These controls are controlled by the operating system running on the CPU 802.

The UA 106 shown in this embodiment is realized by the CPU 802 of the information processing terminal 501 reading and executing a program stored in the ROM 803.

<Example of software configuration of information processing terminal 501>
Fig. 7 is a block diagram showing the software configuration of the information processing terminal 501 in Fig. 4. Fig. 7 mainly describes a technology related to the issuance of a Web Intents request by an application related to the present invention, and a function related to mutual use of functional information using an intent. Note that an intent is a technology for transmitting and receiving data between any applications. This is a technology available on Android (registered trademark), which is a platform developed targeting mobile information terminals. In addition, similar technologies are also implemented in other platforms, but in this embodiment, the technology for transmitting and receiving data between applications in an information processing terminal is called an intent.

In FIG. 7, 501 is the information processing terminal shown in FIG. 4. Here, the information processing terminal 501 will be described as a mobile terminal or a smartphone. An operating system (hereinafter, OS) for controlling the device generally runs on the information processing terminal, and is represented as an OS section 901 in FIG. 7. Also, multiple applications can be installed on the information processing terminal 501. These applications are represented as application sections 902 in FIG. 7. Although only one application section is shown in FIG. 7, multiple applications are actually installed on the information processing terminal 501.

The present invention assumes an environment in which multiple applications that operate as UA 106 in FIG. 1 on the operating system of information processing terminal 501 operate within information processing terminal 501. Note that in this embodiment, a web browser is used as an example of an application that operates as UA 106, but any application that operates as UA 106 may be used. For example, an application such as a spreadsheet software may provide the functions of UA 106. The present invention also includes cases in which the OS operates as UA 106.

The application assumed in this embodiment is an application that can control Web Intents such as a Web browser as UA 106, and is also an application that can transmit and receive data between applications. Technologies for transmitting and receiving data between applications include Web Intents in addition to intents. Example 1 shows an example in which data is transmitted and received between applications using intents. Also, Example 2, which will be described later, shows an example in which data is transmitted and received between applications using Web Intents. However, the applications assumed here are not limited to intents or Web Intents as long as they are capable of transmitting and receiving data between any applications.

The OS section 901 and application section 902 shown in FIG. 7 are realized by the CPU 802 of the information processing terminal 501 reading and executing the OS and application programs stored in the ROM 803.

First, the OS unit 901 will be described.
In the OS unit 901, 906 is a network control unit. The network control unit 906 controls the network controller 805 in Fig. 6. Since the information processing terminal 501 is a small portable terminal, it is assumed that it will be used while moving around, and the network control unit 906 automatically connects to an accessible network depending on the location. In addition, the network control unit 906 communicates with the outside in response to a communication request from the application unit 902. In addition, the network control unit 906 responds to a network connection request from the outside, and distributes the connection request to an appropriate application unit 902.

Reference numeral 904 denotes an intent information input/output unit, and 905 denotes an application information storage unit. When the OS unit 901 receives an intent request from the application unit 902 together with information on the action and type (hereinafter, data type), it requests the intent information input/output unit 904 for an application corresponding to the action and data type. When the intent information input/output unit 904 receives an intent request, it obtains a list of applications corresponding to the received action and data type from the application information storage unit 905. Then, the intent information input/output unit 904 transmits the obtained list of applications to the application unit 902.

Also, 903 is a user input/output unit, which collectively manages the audio control unit 806, display control unit 807, and input control unit 808 in FIG. 6. When the application unit 902 issues a display instruction to the user, the user input/output unit 903 displays the information on the display 814 via the display control unit 807. When the user makes an input via the touch panel 815, the user input/output unit 903 transmits an input signal controlled by the input control unit 808 to the application unit 902.

Next, the application unit 902 will be described.
The application unit 902 includes a service information management unit 908 , a central processing unit 907 , a service information detection unit 909 , a service information input/output unit 910 , and a service information storage unit 911 .

907 is a central processing unit that plays a central role as a web browser. The basic role of this central processing unit 907 is as UA 106 in Web Intents. In addition, the central processing unit 907 also performs basic browsing processing, detection of services 103, and sending and receiving data through intents. Furthermore, when the central processing unit 907 does not use the intents of the OS unit 901, it is also possible for the central processing unit 907 to obtain or provide service information (function information) of Web Intents from other applications using a service information management unit 908. The service information management unit 908 will be described in Example 2 below.

The service information detection unit 909 detects the <intent> tag included in the web page received from the service 103 at the time of access, and recognizes function information for registering functions provided by the service 103. The service information input/output unit 910 controls the input/output of function information to the service information storage unit 911. The service information storage unit 911 stores information such as that shown in FIG. 8.

FIG. 8 is a diagram illustrating an example of function information managed by a Web browser serving as a UA.
For example, in the example shown in FIG. 8 , information including the name 1401 of the function provided by the service, the URI 1402 for accepting the function provided by the service, the action 1403 when accepting a Web Intents request, and the data type 1404 is stored in the service information storage unit 911.

The operation of each module of the application unit 902 will be briefly described below.
A user accesses a certain service (website) using the mechanism of Web Intents by using a web browser (corresponding to UA 106) which is an application of the information processing terminal 501. Then, the service information detection unit 909 of the application unit 902 detects an <intent> tag included in the web page received from the service at the time of access, and recognizes function information (Web Intents service information) for registering a function provided by the service. When the function information of the accessed service is recognized, the central processing unit 907 asks the user via the user input/output unit 903 whether or not to register this function information as a Web Intent. Here, when the user instructs to register, the central processing unit 907 issues an instruction to the service information input/output unit 910 to store the function information specified by the <intent> tag. When the service information input/output unit 910 receives an instruction to store the function information, it stores the function information in the service information storage unit 911.

When a user requests processing from a service, the central processing unit 907 acquires function information from the service information storage unit 911 via the service information input/output unit 910. The central processing unit 907 then displays a list of the acquired function information, and transmits a Web Intents processing request and content information to the service corresponding to the function information selected from the list.

If the list of function information obtained from the service information storage unit 911 does not contain function information corresponding to the function the user wants to use, the Web browser can obtain function information from another Web browser using an intent. In this case, the central processing unit 907 of the Web browser issues a request to the intent information input/output unit 904 of the OS unit 901 to obtain a list of applications that can provide function information. As a result of the request, the central processing unit 907 then receives a list of applications that provide function information. When the user selects an application from this list of applications, the central processing unit 907 makes a function information obtainment request to the selected application using an intent, and obtains the function information.

When the central processing unit 907 receives a request for providing (acquisition request for) functional information from an external application by intent, the central processing unit 907 acquires the functional information from the service information storage unit 911 via the service information input/output 910. Then, the central processing unit 907 provides the acquired functional information to the external application.

<Example of sequence diagram for mutual use of functional information>
Fig. 9 is a sequence diagram illustrating an example of an operation in which a user uses a Web browser to refer to a list of function information managed by another Web browser when using Web Intents. Note that Fig. 9 shows an extension to the basic sequence of Web Intents described in Fig. 2. In Fig. 9, 902 represents a Web browser in the information processing terminal 501, and serves as a UA in terms of Web Intents. In Fig. 9, there are multiple UAs, and the Web browser that requests function information is UserAgent.1 (hereinafter, UA.1), and the Web browser that provides the function information is UserAgent.2 (hereinafter, UA.2).
FIG. 10 is a diagram showing an example of a screen displayed on the web browser screen of UA.1.
11 and 12 are detailed sequence diagrams of a part of the sequence of FIG.

In S1001 of FIG. 9, UA.1 accesses client 101 in response to a user instruction. Then, in S1002, UA.1 receives HTML information including ECMAScript from client 101, whose processing is started by pressing the "Share" button. Then, a screen like that shown in FIG. 10(a) is displayed on the web browser screen of UA.1. On this screen, photo content information can be provided and a request to share the photo content information can be issued to any service by pressing the "Share" button 1101.

In S1003, when the user presses the "Share" button 1101 to instruct use of the service, UA.1 detects that the "Share" button 1101 has been pressed. When UA.1 detects that the "Share" button 1101 has been pressed and determines that the user has instructed use of the service, it moves the process to S1004. In S1004, UA.1 acquires a list of function information registered in the service information storage unit 911 (FIG. 7) based on the action indicating sharing of the photo content and the data type of the file, and displays a selection screen such as that shown in FIG. 10(b) that includes the list (list) of the acquired function information, and presents it to the user.

As shown in FIG. 10(b), the screen displayed in S1004 displays a list 1102 of function information, and a link button 1103 labeled "Service Import" that allows the user to refer to function information already registered in other UAs. This screen also displays an OK button 1104 for confirming the selected function information, and a Cancel button 1105 for canceling the selection of function information.

If the user does not find the function information he or she wants to use in the list of function information 1102 on the screen shown in FIG. 10(b) displayed in S1004 above, the user can use function information registered in another browser. In this case, the user presses the "Service Import" link button 1103 on the screen shown in FIG. 10(b) in S1005.

When UA.1 detects that the "Service Import" link button 1103 has been pressed, it searches for other applications in the information processing terminal 501 that can provide function information (S1006 to S1007). In the first embodiment, as an example, a processing sequence for acquiring function information using an intent from Android (registered trademark) is described. As with Web Intents, intents also enable data transfer between appropriate applications by having the OS mediate between the data type to be transferred and the action to be taken with that data.

Steps S1006 and S1007 will be described in detail below with reference to FIG.
11A, in S1006, UA.1 issues an intent request to the OS unit 901 with the data type set to "application/Web Intents Service" and the action set to "pick" to search for an application that can be requested to provide data. In S1007, the OS unit 901 obtains a list of applications that can provide function information of the service by the intent from the application information storage unit 905. Then, the list is returned to UA.1 via the intent information input/output unit 904 as a list of UAs.

Having acquired the UA list in S1007 above, UA.1 displays a screen including the UA list and presents it to the user in S1008. If the user wishes to use function information registered in a certain UA (here, UA.2) on this screen, the user selects UA.2. When UA.1 detects in S1009 that UA.2 has been selected, it issues a request to acquire a list of function information registered in UA.2 in S1010.

Steps S1010 to S1013 will be described in detail below with reference to FIG.
As shown in Fig. 11B, in S1010, UA.1 makes an intent call to UA.2, requesting processing with a data type of "application/Web IntentsService" and an action of "pick". In response to this request, UA.2 provides UA.1 with a list of function information that can be provided as an intermediate response. Note that this data is actually sent and received via OS 901, but will be described here in a simplified manner.

When UA.1 receives the function information list from UA.2 in S1011, it displays the function information list (list) of UA.2 in S1013. FIG. 10(c) shows an example of the screen displayed on the information processing terminal 501 in S1013. In FIG. 10(c), the parent-child relationship between the list of UAs and the list of function information managed by the UAs is displayed so that it can be seen. For example, in FIG. 10(c), "PhotoServiceD" and "PhotoServiceE" are displayed as function information managed by "browserB" as a UA (1106). However, it is also possible to display only the list of function information not registered in UA.1 without displaying the parent-child relationship. The user confirms the selection of function information by pressing the OK button 1107 with one or more pieces of function information selected. At this time, UA.1 detects that function information has been selected.

The process of detecting the selection of a UA shown in S1009 to S1013 above and acquiring and displaying the function information list registered in the selected UA is repeated the number of times the user selects a UA (S1012).

When UA.1 detects in S1014 that function information registered in UA.2 has been selected from the function information list, in S1015 it issues a request to UA.2 to obtain the selected function information, and obtains the selected function information (S10115 to S1016).

Steps S1015 and S1016 will be described in detail below with reference to FIG.
As shown in Fig. 12A, in S1015, UA.1 uses the intent "pick" to specify the function information to be acquired, and issues an acquisition request to UA.2 using the intent mechanism. In response to this acquisition request, in S1016, UA.2 transmits the specified function information as a response to the intent of 1015. The function information transmitted here is a definition file in which the function information is defined, as shown in Fig. 13.

FIG. 13 is a diagram showing an example of a definition file of the functional information transmitted from UA.2 in S1016.
As shown in FIG. 13, the function information definition file includes the name of a provided function, a URI for receiving the provided function, and an action and data type for providing the provided function.

Returning now to the description of the sequence diagram of FIG.
When UA.1 acquires information necessary for registering the functional information in S1016, UA.1 registers the acquired functional information in itself in S1017. That is, the central processing unit 907 of UA.1 stores the functional information acquired in S1016 in the service information storage unit 911 via the service information input/output unit 910. After that, in S1018, UA.1 displays a selection screen as shown in FIG. 10B again to present a list of functional information registered in itself to the user. When UA.1 detects in S1019 that a certain functional information has been selected by the user from the functional information list displayed in S1018, it proceeds to S1020. In S1020, UA.1 transmits an HTTP request (Web Intent processing request) for processing "share" to the service (here, service 103) corresponding to the selected functional information.

Steps S1020 and S1021 will be described in detail below with reference to FIG.
12B, in S1020, UA.1 issues a Web Intents processing request with a data type of "image/jpeg" and an action of "share" to the service 103. In response to this Web Intents processing request, in S1021, the service 103 executes processing for the Web Intents processing request and returns the execution result to UA.1 as a response. UA.1 then receives the response of S1021.

<Example of UA Processing Flowchart of First Embodiment>
Fig. 14 is a flowchart showing an example of software processing from when the UA receives ECMAScript from a client, to when it acquires function information from outside, and when it issues a request to a service. Note that the processing of this flowchart shows a part of the processing of the software in the information processing terminal 501 shown in Fig. 7. The processing of this flowchart is realized by the CPU 802 of the information processing terminal 501 expanding a program stored in the ROM 803, storage device 809, etc., into the RAM 804 as necessary and executing it.

In S1701, when the network control unit 906 of the information processing terminal 501 receives HTML including ECMAScript for issuing a Web Intents request from the client 101, the process proceeds to S1702.

In S1702, the central processing unit 907 creates a screen based on the received HTML information, displays a screen such as that shown in FIG. 10A via the user input/output unit 903, presents the received information to the user, and proceeds to S1703. In S1703, the central processing unit 907 determines whether or not an instruction to issue a Web Intents request has been received from the user via a screen operation. Note that when the central processing unit 907 detects pressing of the "share" button 1101, it determines that an instruction to issue a Web Intents request has been received.

If it is determined that an instruction to issue a Web Intents request has not been received (No in S1703), the central processing unit 907 returns to the process of S1703 and waits for an instruction to issue from the user. Although not shown, if a request to move to another web page is received at the user's instruction, the central processing unit 907 leaves the process of this flowchart and performs processing according to the request.

On the other hand, if it is determined that an instruction to issue a Web Intents request has been received (Yes in S1703), the central processing unit 907 advances the process to S1704. In S1704, the central processing unit 907 queries the service information input/output unit 910 about the registration of functional information corresponding to the Web Intents request. If the corresponding functional information is registered, the central processing unit 907 displays a list of functional information 1102 as shown in FIG. 10(b) via the user input/output unit 903 and presents it to the user. Then, the process advances to S1705.

In S1705, the central processing unit 907 determines whether or not the "Service Import" link button 1103 has been pressed on the screen shown in FIG. 10(b). If it is determined that the "Service Import" link button 1103 has been pressed (Yes in S1705), the central processing unit 907 advances the process to S1706. In S1706, a function information list acquisition and registration process is executed. Details of S1706 in the first embodiment are shown in FIG. 15, which will be described later. When the process of S1706 is completed, the central processing unit 907 advances the process to S1704 and displays a selection screen (such as the screen in FIG. 10(b)) for a list of function information including the information acquired in S1706.

On the other hand, if it is determined that the "Service Import" link button 1103 was not pressed (No in S1705), the central processing unit 907 advances the process to S1707. In S1707, when the central processing unit 907 detects the selection of functional information by the user, the process advances to S1708. In S1708, the central processing unit 907 creates a Web Intents request using the content information for which an issuance instruction was issued in S1703, and advances the process to S1709. In S1709, the central processing unit 907 issues the Web Intents request created in S1708 to the service corresponding to the functional information selected and detected in S1705, and ends the process of this flowchart.

<Flowchart of function information list acquisition and registration process>
15 is a flowchart showing details of the function information list acquisition and registration process (S1706 in FIG. 14) in Example 1. The process of this flowchart is realized by the CPU 802 of the information processing terminal 501 expanding a program stored in the ROM 803, the storage device 809, etc., into the RAM 804 as necessary and executing the program.

When the function information list acquisition and registration process shown in S1706 of FIG. 14 is started (S1721), the central processing unit 907 advances the process to S1722. In S1722, the central processing unit 907 issues an intent request to the OS unit 901 with the action set to "pick" and the data type set to "Web Intents Service", and advances the process to S1723.

In S1723, the central processing unit 907 determines whether or not it has received a list of applications as a response to the request made by the intent from the OS unit 901. If it determines that it has not received a list of applications from the OS unit 901 (No in S1723), the central processing unit 907 advances the process to S1724. In S1724, it notifies the user (for example, by displaying a message) that a corresponding application was found in response to the intent but no corresponding application exists in the device, and ends the function information list acquisition/registration process (S1735).

On the other hand, if it is determined that the application list has been received from the OS unit 901 (Yes in S1723), the central processing unit 907 advances the process to S1725. In S1725, the central processing unit 907 displays the application list acquired in S1723 on the display 814 via the user input/output 903 and presents it to the user. Then, the process advances to S1726.

In S1726, when the central processing unit 907 detects that the user has selected one application from the list of applications displayed in S1725, the central processing unit 907 advances the process to S1727. In S1727, the central processing unit 907 uses an intent to request a list of function information corresponding to the action "pick" and the data type "Web IntentsService" from the application selected in S1726. Then, the process advances to S1728.

In S1728, the central processing unit 907 receives the list of function information requested in S1727 above, and proceeds to S1729. In S1729, the central processing unit 907 compares the list of function information received in S1728 above with the function information already registered in the service information storage unit 911. As a result of the comparison, the central processing unit 907 excludes the function information that has already been registered, and proceeds to S1730.

In S1730, the central processing unit 907 displays a list of the functional information received via the user input/output unit 903 on the display 814. The screen displayed here is as shown in FIG. 10(c).

In the example of FIG. 10(c), the central processing unit 907 displays a list of applications consisting of "browserB" and "browserC" in S1726. To obtain a function information list registered in "browserB," the user touches "browserB." In response, the central processing unit 907 tilts the triangle on the left side of the screen indicating the directory structure as shown in 1108 in S1730, and displays the function information list 1106 registered in "browserB." From this function information list 1106, the user selects one or more pieces of function information that he or she wishes to import into the application.

Returning now to the description of the flowchart in FIG.
When an operation on the screen displayed in S1730 is detected, the central processing unit 907 advances the process to S1731. In S1731, the central processing unit 907 judges whether or not it has been detected that functional information to be imported has been selected from the functional information list displayed in S1730. If it has been determined that no functional information has been selected and an application (e.g., "browser C") has been selected (No in S1731), the central processing unit 907 advances the process to S1726.

On the other hand, if it is determined that the function information to be imported has been selected from the function information list displayed in S1730 (Yes in S1731), the central processing unit 907 advances the process to S1732. In S1732, the central processing unit 907 uses an intent to request the selected function information from the application that manages the selected function information, and advances the process to S1733.

In S1733, the central processing unit 907 receives the selected function information from the target application and proceeds to S1734. In S1734, the central processing unit 907 registers the received function information in the service information storage unit 911 via the service information input/output unit 910. Then, the function information acquisition/registration process ends (S1735).

As described above, when multiple UAs exist within the same information processing terminal, the intent mechanism can be used to obtain and use function information of services registered in other UAs from the other UAs. Therefore, when multiple UAs exist within the same information processing terminal, it is possible to share function information of services registered separately in each UA.

In the above-mentioned Example 1, a configuration was described in which, for example, intents of an Android (registered trademark)-based platform were used to obtain function information managed by other UAs. In contrast, in Example 2, a configuration is described in which intents are not used, but rather function information is obtained from other UAs using W3C Web Intents.

The service information management unit 908 of the application unit 902 shown in FIG. 7 has the functionality of an HTTP client. The service information management unit 908 issues a request to an external application to acquire functional information. Furthermore, when the service information management unit 908 receives functional information from an external application in response to the acquisition request, it issues a request to store WebIntents service information to the service information input/output unit 910 via the central processing unit 907.

The service information management unit 908 also has the functionality of a Web Intents service. When the service information management unit 908 receives a request to acquire functional information together with action and data type information from an external application using the Web Intents mechanism, it acquires functional information from the service information storage unit 911 via the central processing unit 907 and the service information input/output 910, and provides the acquired functional information to the requester.

<Examples of other sequence diagrams regarding mutual use of functional information>
Fig. 16 is a sequence diagram illustrating another operation in which a list of function information managed by another Web browser is referenced and used in the second embodiment. Note that the same step numbers are assigned to the same steps as in Fig. 9. Only the parts that are different from Fig. 9 will be described below.
FIG. 17 is a detailed sequence diagram of a part of the sequence in FIG.

The processing of S1001 to S1005 is the same as that in FIG. 9, and therefore a description thereof will be omitted. In the information processing terminal 501 of the second embodiment, if the list of function information acquired from the service information storage unit 911 does not contain function information corresponding to the function the user wishes to use, the information processing terminal 501 searches for an application or service (hereinafter simply referred to as a service) capable of providing function information from the local area network (Local Network) 1501. Specifically, when UA.1 detects in S1005 that the user has pressed the "Service Import" link button 1103 (FIG. 10(b)), in S1601 it executes a service search on the Local Network 1501. This network search will be described in detail below with reference to FIG. 17.

17, in S1601, UA.1 searches for services in the Local Network 1501. Here, for example, a technology such as Multicast DNS in Bonjour, which is a zero configuration technology from Apple, is used to search for network services within the link local.
In S1602, UA.1 receives responses from each service. In this embodiment, since the search is performed within the local network 1501, responses can be received not only from services within the same information processing terminal, but also from services within the reach of the network.

Next, in S1603, UA.1 detects and lists services that provide "application/Web Intents Service" as the data type and "pick" as the action from among the services that responded in S1602. Note that if the information required for the detection is insufficient at this time, the information may be obtained by accessing each service that responded in S1602. This process makes it possible to search for services that are present in the local area network and that can provide function information.
Next, in S1604, UA.1 displays the list of services detected in S1603 above, presents it to the user, and proceeds to S1009. The subsequent processing is the same as in Fig. 9, so a description thereof will be omitted.

<Flowchart of function information list acquisition and registration process according to the second embodiment>
18 is a flowchart showing details of the function information list acquisition and registration process (S1706 in FIG. 14) in the embodiment 2. The process of this flowchart is realized by the CPU 802 of the information processing terminal 501 expanding a program stored in the ROM 803, the storage device 809, etc., into the RAM 804 as necessary and executing the program.

When the function information list acquisition and registration process shown in S1706 of FIG. 14 is started (S1741), the central processing unit 907 instructs the service information management unit 908 to execute the process of S1742. In S1742, the service information management unit 908 searches the local network 1501 for applications or services (hereinafter simply referred to as services) that provide functions using the Web Intents mechanism (corresponding to S1601 to S1604 of FIG. 16 and FIG. 17). The search target is a service with the action "pick" and the data type "Web Intents Service". The search request is issued using a service search protocol such as multicast DNS used in Apple's bonjour, etc.

Next, in S1743, the service information management unit 908 determines whether or not one or more corresponding services have been found as a result of the search in S1742. If the service information management unit 908 determines that a corresponding service has not been found (No in S1743), the process proceeds to S1744. In S1744, the service information management unit 908 notifies the user via the central processing unit 907 that no corresponding service exists within the network search range as a result of the service search (for example, displays a message), and ends the function information list acquisition and registration process (S1755).

On the other hand, if the service information management unit 908 determines that one or more corresponding services have been found (Yes in S1743), the process proceeds to S1745. In S1745, the service information management unit 908 displays, via the central processing unit 907, a list of the services acquired via the user input/output 903 in S1743 above, and proceeds to S1746.

In S1746, when the service information management unit 908 detects via the central processing unit 907 that a service has been selected by the user from the list of services displayed in S1745 above, the process proceeds to S1747. In S1747, the service information management unit 908 uses Web Intents to request a list of function information with the action "pick" and the data type "Web IntentsService" from the service selected in S1746 above. Then, the process proceeds to S1748.

In S1748, when the service information management unit 908 receives the function information list requested in S1747 above, the process proceeds to S1749. In S1749, the service information management unit 908, via the central processing unit 907, compares the function information list received in S1748 above with the function information that has already been registered in the service information storage unit 911. As a result of the comparison, the function information that has already been registered is excluded, and the process proceeds to S1750.

In S1750, the service information management unit 908 displays the list of the above-mentioned functional information via the central processing unit 907 and the user input/output unit 903. Here, for example, a screen like that shown in FIG. 10(c) is displayed. When the user wants to obtain a list of functional information registered in a certain application, he/she touches "browser B". Then, the triangle on the left side of the screen indicating the directory structure tilts as shown in 1108, and the functional information list 1106 shown in S1750 is displayed. From this functional information list 1106, the user selects one or more pieces of functional information that he/she wishes to import into the application.

Returning now to the description of the flowchart.
When an operation on the screen displayed in S1750 is detected, the service information management unit 908 advances the process to S1751. In S1751, the service information management unit 908 judges whether or not it has been detected that functional information to be imported has been selected from the functional information list displayed in S1750 via the central processing unit 907. Then, when it has been determined that no functional information has been selected and an application (e.g., "browserC") has been selected (No in S1751), the service information management unit 908 advances the process to S1746.

On the other hand, if it is determined that the function information to be imported has been selected from the function information list displayed in S1750 (Yes in S1751), the service information management unit 908 proceeds to S1752. In S1752, the service information management unit 908 uses Web intents to request the function information from the service that manages the selected function information, and proceeds to S1753.

In S1753, the service information management unit 908 receives the selected function information from the target service and proceeds to S1754. In S1754, the service information management unit 908 registers the received function information in the service information storage unit 911 via the central processing unit 907 and the service information input/output unit 910. Then, the function information acquisition/registration process ends (S1755).

As described above, when multiple UAs exist on the same information processing terminal, it is possible to use the Web Intents mechanism to obtain and use function information for services registered separately for each UA.

In the first embodiment, an example was shown in which intents were used to mutually use function information of functions provided by services between applications inside the information processing terminal 501. In addition, in the second embodiment, an example was shown in which Web Intents were used to mutually use function information with applications on a local network.

However, when a user attempts to obtain function information, the other party to the mutual use does not necessarily have to be an application or service on an internal or local network, but may also be a service on the Internet. For example, when registering function information in a Web browser as a UA, the function information is also registered in a service that manages function information lists on the Internet. Next, the user considers using the service in another Web browser and presses the "Service Import" link button 1103 in FIG. 10(b). The Web browser then connects to the service that manages function information lists on the Internet and issues a request to obtain the function information list. In this way, the other party to the mutual use of function information lists does not necessarily have to be an application on a local network, and the same effects as in the first and second embodiments can be obtained.

As shown in Example 2, when attempting to obtain a function information list using Web Intents, there are cases where function information available in a certain Web browser cannot be used in the Web browser itself. For example, assume that the URL of a function provided by a service present in the information processing terminal 501 is a URL indicating a local loopback address (http://127.0.0.1/~). Even if function information including such a URL is provided to the requesting Web browser, the provided Web browser (the requesting Web browser) cannot use the provided function of the service corresponding to the function information via the network.

In such a case, the web browser on the providing side is configured to provide only available function information according to the conditions of the side requesting the function information (request side). In addition, functions provided by a service may be used by specifying special actions and types in addition to URLs. Therefore, the providing side is configured to provide only available function information on the requesting side according to the action and type requested by the requesting side. With the above configuration, it is possible to prevent the unnecessary registration of function information that cannot be used by the requesting side, as described above, and improve user convenience.

Another possible workaround would be for the web browser that receives the function information to determine whether it can be used when it acquires the function information, and if the function information is unavailable, not display the function information to the user as an option. This configuration can also prevent the unnecessary registration of function information that cannot be used by the requester, improving user convenience.

As described above, according to the present invention, it is possible to improve the usability of new linkage mechanisms such as Web Intents that are currently being proposed. For example, when a single information processing terminal is provided with multiple relay functions required to provide a linkage mechanism for new web services such as Web Intents, it is possible to appropriately share at least a portion of the function information between those relay functions. As a result, the user does not need to repeatedly register the same provided functions for each relay function, improving user convenience.

It goes without saying that the configurations and contents of the various data described above are not limited to those described above, and the data may have various configurations and contents depending on the application and purpose.
Although one embodiment has been described above, the present invention can be embodied, for example, as a system, an apparatus, a method, a program, a storage medium, etc. Specifically, the present invention may be applied to a system composed of multiple devices, or may be applied to an apparatus composed of a single device.
Furthermore, any combination of the above embodiments is also included in the present invention.

(Other Examples)
The present invention can also be realized by executing the following process: That is, software (programs) that realize the functions of the above-described embodiments are supplied to a system or device via a network or various storage media, and the computer (or CPU, MPU, etc.) of the system or device reads and executes the program.
Furthermore, the present invention may be applied to a system made up of a plurality of devices, or to an apparatus made up of a single device.
The present invention is not limited to the above-mentioned embodiment, and various modifications (including organic combinations of the embodiments) are possible based on the spirit of the present invention, and are not excluded from the scope of the present invention. In other words, the present invention includes all configurations that combine the above-mentioned embodiments and their modifications.

Claims (30)

A system including a server and an information processing terminal,
The server,
a means for accepting access using a web browser installed on the information processing terminal;
means for providing the web browser with page data including a description of a shared object and data to be shared corresponding to the shared object;
The information processing terminal includes:
a display control means for controlling a selection screen that accepts an operation to select, from a plurality of services, a service with which the data to be shared, which corresponds to the shared object on which a user operation has been performed on a page displayed by using the web browser based on the page data, is to be shared;
means for sharing the data to be shared with a service that is a sharing destination selected based on the operation;
On the selection screen, information on the plurality of services as candidates for sharing destinations is displayed by an operating system installed on the information processing terminal.
A system characterized by: The system described in claim 1, characterized in that in the display control, the selection screen is displayed in front of the page displayed by the web browser on the display unit of the information processing terminal and on which the shared object is placed. 3. The system according to claim 1, wherein the selection screen displays information about the plurality of services including services managed by the operating system as candidates for sharing destinations. 4. The system according to claim 1, wherein the service corresponds to an application installed on the information processing terminal. 5. The system according to claim 1, wherein the selection screen includes an instruction section for canceling sharing of the data to be shared. 6. The system according to claim 1, wherein the information about the service includes a name of the service. The system according to any one of claims 1 to 5, wherein the information of the service includes an icon of the service. A system as described in any one of claims 1 to 7, characterized in that the description of the page data includes a predetermined function called by the web browser for the selection screen in response to a user instruction for the shared object. 9. The system according to claim 1, wherein the information processing terminal is a smartphone. The system according to any one of claims 1 to 9, wherein the data to be shared is image data. The system according to any one of claims 1 to 10, characterized in that in the display control, the selection screen is displayed in a position that does not overlap a display area of a URL indicating a source of the page data of the web browser. 12. The system according to claim 1, wherein the server accepts the access using the web browser via the Internet. A method in a system including a server and an information processing terminal, comprising:
The server,
accepting access using a web browser installed on the information processing terminal;
providing page data to the web browser, the page data including a description of a shared object and data corresponding to the shared object that is to be shared;
The information processing terminal includes:
performing display control of a selection screen that accepts an operation for selecting, from a plurality of services, a service with which the data to be shared, which corresponds to the shared object on which a user operation has been performed on a page displayed by using the web browser based on the page data;
Sharing the data to be shared with a service that is a sharing destination selected based on the operation,
On the selection screen, information on the plurality of services as candidates for sharing destinations is displayed by an operating system installed on the information processing terminal.
A method comprising: An information processing terminal,
means for receiving, via a network, page data including a description of a shared object and data to be shared corresponding to the shared object;
a display control means for controlling a selection screen that accepts an operation to select, from a plurality of services, a service with which the to-be-shared data corresponding to the shared object on which a user operation has been performed on a page displayed using a web browser installed on the information processing terminal based on the page data; and
means for sharing the data to be shared with a service that is a sharing destination selected based on the operation;
On the selection screen, information on the plurality of services as candidates for sharing destinations is displayed by an operating system installed on the information processing terminal. The information processing terminal according to claim 14, characterized in that, in the display control, the selection screen is displayed in front of the page displayed by the web browser on the display unit of the information processing terminal and on which the shared object is placed. 16. The information processing terminal according to claim 14, wherein information on the plurality of services including services managed by the operating system as candidates for sharing destinations is displayed on the selection screen. 17. The information processing terminal according to claim 14, wherein the service corresponds to an application installed on the information processing terminal. 18. The information processing terminal according to claim 14, wherein the selection screen includes an instruction section for canceling sharing of the data to be shared. 19. The information processing terminal according to claim 14, wherein the information about the service includes a name of the service. 19. The information processing terminal according to claim 14, wherein the information about the service includes an icon of the service. 21. The information processing terminal according to claim 14, wherein the information processing terminal is a smartphone. 22. The information processing terminal according to claim 14, wherein the display control includes displaying the selection screen at a position that does not overlap a display area of a URL indicating a source of the page data of the web browser. A method in an information processing terminal, comprising:
receiving, via a network, page data including a description of a shared object and data to be shared corresponding to the shared object;
performing display control of a selection screen that accepts an operation for selecting, from a plurality of services, a service with which the to-be-shared data corresponding to the shared object on which a user operation has been performed on a page displayed using a web browser installed on the information processing terminal based on the page data;
and sharing the data to be shared with a service that is a sharing destination selected based on the operation,
The method according to the present invention, characterized in that, on the selection screen, information on the plurality of services as candidates for sharing destinations is displayed by an operating system installed on the information processing terminal. An operating system for an information processing terminal, comprising:
The information processing terminal,
a display control means for controlling the display of a selection screen for accepting an operation to select from a plurality of services a service with which the data to be shared that corresponds to the shared object on which a user operation has been performed on a page displayed using a web browser installed on the information processing terminal based on page data received via a network, the page including a description of a shared object and data to be shared that corresponds to the shared object;
causing the service to be the sharing destination selected based on the operation to function as a means for sharing the data to be shared;
The operating system, wherein information on the plurality of services as candidates for sharing destinations is displayed by the operating system on the selection screen. The operating system according to claim 24, characterized in that in the display control, the selection screen is displayed in front of the page displayed by the web browser on the display unit of the information processing terminal and on which the shared object is placed. 26. The operating system according to claim 24, wherein the selection screen displays information about the plurality of services including services managed by the operating system as candidates for sharing destinations. 27. An operating system according to any one of claims 24 to 26, wherein the services correspond to applications installed on the information processing terminal. 28. The operating system according to claim 24, wherein the selection screen includes an instruction section for canceling sharing of the data to be shared. 29. An operating system according to any one of claims 24 to 28, wherein the information about the service includes a name of the service. 29. The operating system of claim 24, wherein the information of the service includes an icon of the service.

Images