Abstract:
An information processing device including: a memory, and a processor coupled to the memory and the processor configured to: execute an application software, execute a specified process for coordinating a software module described in a first language with a software module described in a second language that is different from the first language, and load a device driver for the application software using a peripheral device, the device driver including a first software module described in the first language and a second software module described in the second language, the first software module being a software module in which a plurality of first interfaces are defined, the second software module being a software module in which a plurality of second interfaces are defined, the plurality of first interfaces being associated with the plurality of second interfaces respectively.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application is based upon and claims the benefit of priority of the prior Japanese Patent Application No. 2015-194437, filed on Sep. 30, 2015, the entire contents of which are incorporated herein by reference. 
       FIELD 
       [0002]    The disclosed technology is related to an information processing device, an information processing method, and an information processing program. 
       BACKGROUND 
       [0003]    In recent years, realization of Internet of things (IoT) in which various devices and sensors are coupled to networks has been advanced. As a method for coupling these devices and sensors (hereinafter, also called “peripheral devices”) to networks, there is a method for directly coupling to the Internet via mobile phone networks and so forth. In addition, as another method, there is a case of coupling via smart devices such as smartphones and tablets, carried around by persons. 
         [0004]    In a case of considering trying to provide an application (hereinafter, also called an “app” as an abbreviation of “application”) for coupling to, via a smart device, and using the peripheral devices, it is desirable to implement, in the app, communication protocols corresponding to these peripheral devices. In the communication protocols corresponding to the peripheral devices, there are parts specific to the respective devices. Therefore, in order to implement the communication protocols in the corresponding smart device, a device maker creates and provides an app to users in many cases. However, in this case, it is desirable to prepare an app for each of devices to be used, and it has a disadvantage for users. 
         [0005]    Therefore, there is a method in which, in order to enable to access peripheral devices by using application programming interfaces (APIs), a device maker provides, to app developers, software modules in which parts specific to the respective peripheral devices are described. In, for example, the Device WebAPI Consortium, a method for creating device drivers in accordance with specifications of the consortium, thereby enabling an app to access devices via the WebAPI, is proposed and implemented. 
         [0006]    In addition, as a form of an app provided in a smart device, there is a form called a hybrid app. The hybrid app is an app having, for example, a form in which both a web technology such as a hypertext markup language (HTML) or JavaScript (registered trademark) and a native language such as Java (registered trademark) or a C language are used. According to the hybrid app, a part desired to access APIs provided by an operating system (OS) is described by using the native language, and a part described by using the native language is accessed from the web technology. From this, it becomes possible to utilize the functions of the OS by using the web technology. 
         [0007]    In other words, it is possible to describe, by using the native language, a part to access peripheral devices and to describe, by using the web technology, a large part of an app including user interfaces (UIs). In addition, from this, it becomes possible to use as one app on the smart device while not accessing the web technology by using a web browser. While a large number of web browsers are used in personal computers, the number of apps installed and used in smart devices is larger than the number of apps used via web browsers, in the smart devices. In view of such a background, there is important a form called the hybrid app, in which a developer, who has developed apps for web browsers by using a personal computer and who is acquainted with the web technology, is able to develop apps for smart devices. 
         [0008]    Here, device drivers that access peripheral devices by using the above-mentioned APIs utilize the APIs provided by the OS. Therefore, it is desirable to describe the device drivers by using the native language. Since device drivers of a device to perform communication by using, for example, the Bluetooth (registered trademark) are desired to access APIs, related to the Bluetooth and provided by the OS, the device drivers are described by using the native language. Therefore, there is proposed a method for realizing, by using the native language, minimum functions used for accesses to devices and describing many portions of the device drivers by using the web technology. This method reduces an effort of creating an app to enable a terminal device to control an external device, the terminal device not being authorized to incorporate thereinto a device driver for control of the external device. Specifically, in this method, a general-purpose driver is preliminarily incorporated into the OS, and an application includes a driver library. The driver library is provided, by the application, with a first control instruction in a form recognizable by the application and converts the first control instruction into a second control instruction in a form able to be delivered to the external device. The general-purpose driver transmits, to the external device, the converted second control instruction output by the driver library. 
       CITATION LIST 
     Patent Literature 
       [0000]    
       
         [Patent Literature 1] Japanese National Publication of International Patent Application No. 2000-510626 
         [Patent Literature 2] Japanese Laid-open Patent Publication No. 2005-157427 
         [Patent Literature 3] Japanese Laid-open Patent Publication No. 2013-250739 
         [Patent Literature 4] Japanese Laid-open Patent Publication No. 2015-162214 
       
     
       SUMMARY 
       [0013]    According to an aspect of the invention, an information processing device includes a memory, and a processor coupled to the memory and the processor configured to: execute an application software, execute a specified process for coordinating a software module described in a first language with a software module described in a second language that is different from the first language, and load a device driver for the application software using a peripheral device, the device driver including a first software module described in the first language and a second software module described in the second language, the first software module being a software module in which a plurality of first interfaces are defined, the second software module being a software module in which a plurality of second interfaces are defined, the plurality of first interfaces being associated with the plurality of second interfaces respectively, wherein for using the peripheral device the application software is configured to make a first access to a first interface selected from the plurality of first interfaces, the first software module is configured to make a second access to the specified process based on the first access, the specified process is configured to make a third access to a second interface selected from the plurality of second interfaces based on the second access and associated with the selected first interface, the second software module is configured to make a fourth access to the peripheral device based on the third access. 
         [0014]    The object and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the claims. 
         [0015]    It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, as claimed. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0016]      FIG. 1  is a block diagram illustrating a schematic configuration of an information processing system according to first to fifth embodiments. 
           [0017]      FIG. 2  is a functional block diagram illustrating a schematic configuration of a mobile terminal according to the first embodiment. 
           [0018]      FIG. 3  is a diagram illustrating an example of a correspondence table between a type of peripheral device and a service UUID. 
           [0019]      FIG. 4  is a diagram illustrating an example of a correspondence table between a service UUID, a device ID, and a URL. 
           [0020]      FIG. 5  is a diagram illustrating an example of a device driver. 
           [0021]      FIG. 6  is a diagram illustrating an example of an API table. 
           [0022]      FIG. 7  is a block diagram illustrating a schematic configuration of a computer to function as mobile terminals according to the first to fifth embodiments. 
           [0023]      FIG. 8  is a flowchart illustrating an example of information processing in the first embodiment. 
           [0024]      FIG. 9  is a diagram for explaining an outline of the information processing. 
           [0025]      FIG. 10  is a functional block diagram illustrating a schematic configuration of the mobile terminal according to the second embodiment. 
           [0026]      FIG. 11  is a diagram illustrating an example of an API correspondence table. 
           [0027]      FIG. 12  is a functional block diagram illustrating a schematic configuration of the mobile terminal according to the third embodiment. 
           [0028]      FIG. 13  is a flowchart illustrating an example of information processing in the third embodiment. 
           [0029]      FIG. 14  is a functional block diagram illustrating a schematic configuration of the mobile terminal according to the fourth embodiment. 
           [0030]      FIG. 15  is a flowchart illustrating an example of information processing in the fourth embodiment. 
           [0031]      FIG. 16  is a functional block diagram illustrating a schematic configuration of the mobile terminal according to the fifth embodiment. 
           [0032]      FIG. 17  is a flowchart illustrating an example of information processing in the fifth embodiment. 
       
    
    
     DESCRIPTION OF EMBODIMENTS 
       [0033]    Along with the popularization of the IoT, various devices exist in the world. Accordingly, there may be assumed a way to use, such as carrying around only a terminal such as a smartphone, without carrying around a device, and using a device existing in the place. In the related art, since it is difficult to extend a general-purpose driver side, it is difficult to utilize a device with which a general-purpose driver is not able to deal. In addition, it is difficult to preliminarily create a general-purpose driver so as to be able to deal with a device likely to be used. 
         [0034]    As one aspect, an object of the disclosed technology is to dynamically replace device drivers for using peripheral devices in a hybrid application. 
         [0035]    Hereinafter, examples of embodiments of the disclosed technology will be described in detail with reference to drawings. 
       First Embodiment 
       [0036]    As illustrated in  FIG. 1 , an information processing system  10  according to a first embodiment includes a mobile terminal  20 , a peripheral device  50 , a device driver distribution server  52 , and an application (hereinafter, “application” is abbreviated as “app” in some cases) distribution server  54 . 
         [0037]    The mobile terminal  20  is an information processing device such as, for example, a smartphone or a tablet terminal. On the mobile terminal  20 , an app to utilize the peripheral device  50  operates. In addition, while details will be described later, a case where the app to utilize the peripheral device  50  is a hybrid app to use both a web technology and a native language will be described in the present embodiment. 
         [0038]    The peripheral device  50  is an instrument such as, for example, a printer, a card reader, or one of various kinds of sensors. The peripheral device  50  and the mobile terminal  20  are coupled to each other by wireless communication or wired communication. The peripheral device  50  and the mobile terminal  20  communicate with each other by using, for example, the Bluetooth (registered trademark) or a wireless local area network (LAN). 
         [0039]    The device driver distribution server  52  is an information processing device such as a general server device and stores device drivers in an internally provided storage device or an externally coupled storage device. In accordance with a request from the mobile terminal  20 , the device driver distribution server  52  distributes device drivers to the mobile terminal  20 . 
         [0040]    The app distribution server  54  is an information processing device such as a general server device and stores app programs in an internally provided storage device or an externally coupled storage device. In accordance with a request from the mobile terminal  20 , the app distribution server  54  distributes app programs to the mobile terminal  20 . 
         [0041]    Each of the device driver distribution server  52  and the app distribution server  54  and the mobile terminal  20  are coupled to each other by wireless communication or wired communication. Each of the device driver distribution server  52  and the app distribution server  54  and the mobile terminal  20  communicate with each other by using, for example, a wireless LAN or a mobile network such as the 3G or the Long Term Evolution (LTE). 
         [0042]      FIG. 2  illustrates a schematic configuration of the mobile terminal  20 . The mobile terminal  20  functionally includes an app reception unit  31 , an app starting unit  33 , a device detection unit  35 , a driver acquisition unit  36 , and a device information exchange unit  38 . In addition, the mobile terminal  20  includes a loading unit  21 , a coordination unit  34 , a communication unit  39 , and a user interface (UI) control unit  40 , the coordination unit  34  including an access unit  22 . Furthermore, an app storage unit  32 , a driver storage unit  37 , and an application programming interface (API) table  25  are provided in a predetermined storage area of the mobile terminal  20 . Hereinafter, the individual functional units of the mobile terminal  20  will be described. 
         [0043]    The communication unit  39  controls communication between the mobile terminal  20  and the peripheral device  50  and communication between the mobile terminal  20  and each of the device driver distribution server  52  and the app distribution server  54 . 
         [0044]    The UI control unit  40  controls UIs to provide a unit for presenting Information to a user and a unit for inputting information from the user. Specifically, the UI control unit  40  controls display of an icon for instructing to start an app, reception of an access request or a control instruction for the peripheral device  50 , screen display based on information acquired from the peripheral device  50 , and so forth. 
         [0045]    The app reception unit  31  receives and stores an app program from the app distribution server  54  via the communication unit  39  and in the app storage unit  32 . 
         [0046]    The app starting unit  33  reads, from the app storage unit  32 , an app program of an app instructed to be started by a user via the UI control unit  40  and starts an app  45 . The user may touch, for example, an icon displayed in a display unit in the mobile terminal  20 , thereby performing the instruction from the user. 
         [0047]    As described above, in the present embodiment, the hybrid app is used as the app  45  to operate on the mobile terminal  20 . The hybrid app is made up of a part described by using a web technology and a part described by using a native language. In a case where the mobile terminal  20  is equipped with, for example, an Android (registered trademark) operating system (OS), the hybrid app is able to utilize the Java (registered trademark) and to further utilize a C language, as the native language. In addition, the hybrid app is able to utilize a hypertext markup language (HTML), the JavaScript (registered trademark), cascading stylesheets (CSS), and so forth, which each serve as the web technology. 
         [0048]    In addition, as a technology for realizing, in the hybrid app, coordination between the part described by using the web technology and the part described by using the native language, a framework called Apache Cordova is provided. The Apache Cordova is a platform including a JavaScript part and a Java part. In a case of using the Apache Cordova, an app developer is able to create one app by describing a web technology part and building, along therewith, a platform part of a Cordova plug-in to provide a native function, as a native part. 
         [0049]    In a stage in which the app starting unit  33  starts the app  45  to utilize the peripheral device  50 , a device driver is not yet read, and an execution environment on the mobile terminal  20  is configured by the app  45  and a runtime. Note that, in the present embodiment, the runtime is a part other than the app  45  or a device driver  30 , supposed to be replaced, and includes the individual functional units of the mobile terminal  20  illustrated in  FIG. 2 . 
         [0050]    The app  45  started by the app starting unit  33  outputs, to the device detection unit  35 , an access request for the peripheral device  50 , indicated by a user operation. Note that this access request includes information for specifying what kind of peripheral device  50  is intended to be accessed. In a case of an access request from, for example, an app to measure blood pressure, information for specifying a sphygmomanometer is included as the type of the peripheral device  50 . 
         [0051]    In addition, based on an operation performed by a user or an instruction from another process of the app  45 , the app  45  started by the app starting unit  33  delivers, to a JavaScript part  30 A to be described later, a control instruction for the peripheral device  50 . Specifically, the app  45  calls an API of the JavaScript part  30 A, which corresponds to the control instruction. In addition, the app  45  receives a response from the JavaScript part  30 A, which corresponds to the API calling, and delivers the received response to the UI control unit  40 . 
         [0052]    Upon receiving the access request for the peripheral device  50 , the device detection unit  35  detects the peripheral device  50  via the communication unit  39 . The detection of the peripheral device  50  may be performed by scan processing compliant with a communication standard with the peripheral device  50 . In a case of utilizing, for example, the Bluetooth (registered trademark) for communication with the peripheral device  50 , the device detection unit  35  performs the scan processing compliant with the specification of the Bluetooth. In addition, in a case of utilizing a wireless LAN for communication with the peripheral device  50 , the device detection unit  35  performs the scan processing compliant with the specification of the wireless LAN, by using, for example, universal plug and play (UPnP) or the like. 
         [0053]    More specifically, in a case of utilizing, for example, the Bluetooth Low Energy (BLE) for communication between the mobile terminal  20  and the peripheral device  50 , the device detection unit  35  receives advertising periodically transmitted by the peripheral device  50 . The advertising includes the service universally unique identifier (UUID) and the device ID of the peripheral device  50  that transmits that advertising. The service UUID is identification information for the type of the peripheral device  50 . The device ID is identification information for the peripheral device  50 , independently set by a device vendor. 
         [0054]    The device detection unit  35  holds, for example, such a correspondence table as illustrated in  FIG. 3  between the type of the peripheral device  50  and the service UUID thereof and references the correspondence table at a time of detection of the peripheral device  50 . In addition, the device detection unit  35  detects the peripheral device  50  that transmits the advertising including the service UUID corresponding to the type of the peripheral device  50  included in the access request from the app  45 . The device detection unit  35  notifies the driver acquisition unit  36  of the service UUID and the device ID included in the advertising transmitted by the detected peripheral device  50 . 
         [0055]    The driver acquisition unit  36  requests, from the device driver distribution server  52  via the communication unit  39 , a device driver to be used by the app  45  to utilize the peripheral device  50  indicated by the information given notice of by the device detection unit  35  and downloads the device driver. The driver acquisition unit  36  holds, for example, such a correspondence table as illustrated in  FIG. 4  between a service UUID, a device ID, and a URL indicating an acquisition destination of a device driver for the peripheral device  50  identified by the service UUID and the device ID thereof. In addition, the driver acquisition unit  36  acquires, from the correspondence table, a URL corresponding to a service UUID and a device ID given notice of by the device detection unit  35  and accesses the device driver distribution server  52  and accesses the device driver distribution server  52 , thereby download the corresponding device driver. 
         [0056]    In the present embodiment, the device driver includes a module (first module) described by using a web technology and a module (second module) described by using a native language. Hereinafter, it is assumed that, as illustrated in  FIG. 5 , the device driver  30  including a JavaScript part  30 A to serve as the first module and a Java part  30 B to serve as the second module is downloaded, and the device driver  30  will be described. 
         [0057]    Note that regarding the downloading of the device driver  30 , the JavaScript part  30 A and the Java part  30 B may be separately downloaded or one file into which these are compressed may be downloaded. In addition, before the downloading of the device driver  30 , an information file in which information of the device driver  30  is written may be downloaded. It is assumed that by accessing a URL acquired from, for example, the correspondence table illustrated in  FIG. 4 , an information file illustrated as follows is downloaded. 
         [0058]    {“java_driver”:“driver.jar”,“java_driver_class”:“com.fujitsu.jp.driver. BloodPressure”,“js_driver”:“driver.js”} 
         [0059]    Based on this information file, it is found that a driver.jar file to serve as the Java part  30 B and a driver.js file to serve as the JavaScript part  30 A exist in the device driver  30 . Note that the information file of the above-mentioned example includes a class name defined in the Java part  30 B. This class name is described in the information file so as to be used in processing in a subsequent stage, and details thereof will be described later. Based on this information file and the URL from which this information file is downloaded, the driver acquisition unit  36  creates a URL for downloading a file of the Java part  30 B and a file of the JavaSacript part  30 A. In a case of already acquiring such an information file as described above regarding the device driver  30  corresponding to, for example, a service UUID=0x1810 and a device ID=0x12340001 in the correspondence table illustrated in  FIG. 4 , the driver acquisition unit  36  creates the following URL 
         [0060]    &lt;URL for Java Part  30 B&gt; 
         [0061]    http://jp.fujitsu.com/driver/blood_pressure/driver.jar 
         [0062]    &lt;URL for JavaScipt Part  30 A&gt; 
         [0063]    http://jp.fujitsu.com/driver/blood_pressure/driver.js 
         [0064]    The driver acquisition unit  36  accesses the device driver distribution server  52  by using the created URL, thereby downloading the file of the Java part  30 B and the file of the JavaScript part  30 A. The driver acquisition unit  36  stores the downloaded device driver  30  in the driver storage unit  37 . In addition, in a case of already downloading the information file, the driver acquisition unit  36  stores the information file in the driver storage unit  37 . 
         [0065]    The loading unit  21  loads the lava part  30 B of the device driver  30  stored in the driver storage unit  37 . In, for example, the Android OS, an API for reading a jar file serving as a class file of the Java is provided. By using that API, the loading unit  21  is able to load the Java part  30 B. 
         [0066]    In accordance with a Java object corresponding to an API called by the access unit  22  to be described later, the loaded Java part  30 B notifies the device information exchange unit  38  of information for controlling the peripheral device  50 . This processing is performed by calling an API of, for example, the Android OS. In addition, the loaded Java part  30 B receives a response from the device information exchange unit  38 , which corresponds to a control instruction, and replies to the coordination unit  34 . 
         [0067]    In addition, at a time of loading the Java part  30 B, the loading unit  21  acquires information (hereinafter, called “API information”) to be used to call an API defined in the Java part  30 B and stores the information in the API table  25 . In order to access a Java object for controlling the peripheral device  50 , it is desirable to call an API to access a method within a class defined in the Java part  30 B. In order to call this API, a class name and a method name, which are to be accessed, are desired. Therefore, in the present embodiment, a class name and a method name, defined in the Java part  30 B, are acquired and stored as the API information while being associated with a corresponding Java object. 
         [0068]    Specifically, from an information file stored in the driver storage unit  37 , the loading unit  21  acquires the class name defined in the Java part  30 B. Note that an acquisition method for the class name is not limited to a case of acquiring from the information file. Like the device driver  30  illustrated in  FIG. 5 , in place of the information file, in, for example, the JavaScript part  30 A, the class name defined in the Java part  306  may be described in advance, and the JavaScript part  30 A may notify the loading unit  21  of the class name. In that case, the class name does not have to be described in the information file. Note that the example of  FIG. 5  illustrates that a class name such as “http://jp.fujitsu.com/driver/blood_pressure” is defined in the Java part  30 B of a file called “driver.jar”. 
         [0069]    By using the acquired class name, the loading unit  21  accesses a class of the Java part  30 B of the device driver  30  and acquires a method name defined in the class. In addition, the acquired class name and method name are stored in, for example, such an API table  25  as illustrated in  FIG. 6 . A class and a method are saved, as an object of the Java, on a memory, and information is able to be acquired by accessing the object. Accordingly, as illustrated in the API table  25  in  FIG. 6 , a class name and a method name are stored as the API information while being associated with a corresponding Java object. 
         [0070]    In addition, the loading unit  21  imports the JavaScript part  30 A of the device driver  30  stored in the driver storage unit  37 . In the JavaScript, an API able to execute a character string as a program described by using the JavaScript is provided as standard. By calling that API, the loading unit  21  imports the JavaScript part  30 A. 
         [0071]    If an API corresponding to a control instruction from the app  45  is called, the imported JavaScript part  30 A converts, into a general-purpose API, information of a class name, a method name, an argument, and a callback function that correspond to the control instruction. In addition, the JavaScript part  30 A delivers the general-purpose API to the access unit  22  via the coordination unit  34 . The general-purpose API is an API able to call the coordination unit  34  serving as a portion of the runtime, from the JavaScript part  30 A serving as the web technology. Hereinafter, an example of the information converted into the general-purpose API is illustrated. 
         [0072]    this.device.callNative(“com.fujitsu.jp.driver.BloodPressure”, “GetSystolic”, params, function(info){alert(‘callNative ok’: + info);}, function( ) {alert(‘callNative not ok’);}); 
         [0073]    In the above-mentioned example, callNative is a common interface between the JavaScript part  30 A serving as the web technology and the runtime. “com.fujitsu.jp.driver.BloodPressure” is a class name, “GetSystolic” is a method name, and params is an argument. In addition, function(info) and function( ) are callback functions. In other words, in the general-purpose API, an API called, in the JavaScript part  30 A, by the app  45  is an argument of a function indicating a common interface. From this, the coordination unit  34  does not have to prepare an API for each of methods delivered by the app  45  and is able to deal with various control instructions (methods) delivered by the app  45  only by preparing the API corresponding to the common interface. 
         [0074]    In addition, the imported JavaScript part  30 A receives, from the coordination unit  34  as a response to the general-purpose API, a response made by the peripheral device  50 . In addition, the JavaScript part  30 A replies, with the received response, to the app  45  that called an API of the JavaScript part  30 A. 
         [0075]    The coordination unit  34  is a function of realizing, in the hybrid app, coordination between a part described by using the web technology and a part described by using the native language, and, for example, the above-mentioned Apache Cordova may be applied thereto. Upon receiving the general-purpose API from the JavaScript part  30 A, the coordination unit  34  delivers the general-purpose API to the access unit  22 . In addition, upon receiving a response from the Java part  30 B, the coordination unit  34  returns, to the JavaScript part  30 A, the received response as an argument of a callback function included in the general-purpose API. 
         [0076]    The access unit  22  functions as a plug-in of the coordination unit  34 . The access unit  22  receives the general-purpose API from the JavaScript part  30 A via the coordination unit  34 . The access unit  22  extracts the class name and the method name included in the general-purpose API and references the API table  25 , thereby acquiring the corresponding Java object. In addition, the access unit  22  calls an API of the Java part  30 B, which corresponds to the acquired Java object. 
         [0077]    In accordance with the information given notice of by the Java part  30 B, the device information exchange unit  38  accesses the peripheral device  50  via the communication unit  39  and exchanges information with the peripheral device  50 . The device information exchange unit  38  responds to the Java part  30 B with information acquired from the peripheral device  50 . 
         [0078]    The mobile terminal  20  may be realized by, for example, a computer  60  illustrated in  FIG. 7 . The computer  60  includes a CPU  61 , a memory  62  to serve as a temporary storage area, and a non-volatile storage unit  63 . In addition, the computer  60  includes an input-output device  64 , a read/write (R/W) unit  65  to control reading and writing of data from and to a recording medium  69 , and a network I/F  66  to be coupled to a network such as the Internet. The CPU  61 , the memory  62 , the storage unit  63 , the input-output device  64 , the R/W unit  65 , and the network I/F  66  are coupled to one another via a bus  67 . 
         [0079]    The storage unit  63  may be realized by a hard disk drive (HDD), a solid state drive (SSD), a flash memory, or the like. In the storage unit  63  to serve as a storage medium, an information processing program  70  for causing the computer  60  to function as the mobile terminal  20  is stored. In addition, the storage unit  63  includes an API information storage area  75 , in which API Information to configure the API table  25  is stored, and a data storage area  81  to function as the app storage unit  32  and the driver storage unit  37 . In addition, in the storage unit  63 , programs such as an OS and so forth are stored while the illustrations thereof are omitted. 
         [0080]    The CPU  61  reads and deploys the information processing program  70  from the storage unit  63  and in the memory  62  and sequentially executes processes included in the information processing program  70 . In addition, the CPU  61  deploys, in the memory  62 , the API information stored in the API information storage area  75 , as the API table  25 . 
         [0081]    The information processing program  70  includes a loading process  71 , an access process  72 , and an information processing process  80 . The CPU  61  executes the loading process  71 , thereby operating as the loading unit  21  illustrated in  FIG. 2 . In addition, the CPU  61  executes the access process  72 , thereby operating as the access unit  22  illustrated in  FIG. 2 . In addition, the CPU  61  executes the information processing process  80 , thereby operating as each of the app reception unit  31 , the app starting unit  33 , the device detection unit  35 , the driver acquisition unit  36 , the device information exchange unit  38 , the communication unit  39 , and the UI control unit  40  illustrated in  FIG. 2 . From this, the computer  60  that executes the information processing program  70  turns out to function as the mobile terminal  20 . 
         [0082]    Next, operations of the information processing system  10  according to the first embodiment will be described. It is assumed that app programs of apps to utilize the peripheral device  50  are stored in the app storage unit  32 . If a user instructs to start an app to utilize the peripheral device  50 , an information processing routine illustrated in  FIG. 8  is executed in the mobile terminal  20 . 
         [0083]    In step S 11 , the app starting unit  33  reads, from the app storage unit  32 , an app program of the app instructed to be started by the user, thereby starting the app  45 . 
         [0084]    Next, in step S 12 , the app  45  started by the app starting unit  33  determines whether or not a request to access the peripheral device  50  to be used by the app  45  is received. In a case where no access request is received, the determination in the present step is repeated until an access request is received, and in a case where the access request is received, the processing makes a transition to step S 13 . 
         [0085]    In step S 13 , the app  45  outputs, to the device detection unit  35 , an access request specifying the type of the peripheral device  50 . In addition, based on scan processing, the device detection unit  35  detects the peripheral device  50  via the communication unit  39 . At this time, the device detection unit  35  acquires the service UUID and device ID of the peripheral device  50  and notifies the driver acquisition unit  36  thereof. 
         [0086]    Next, in step S 14 , the driver acquisition unit  36  references such a correspondence table as illustrated in  FIG. 4 , thereby acquiring a URL corresponding to the service UUID and device ID given notice of by the device detection unit  35 . In addition, by using the acquired URL, the driver acquisition unit  36  accesses the device driver distribution server  52 , thereby downloading the device driver  30  including the JavaScript part  30 A and the Java part  30 B. 
         [0087]    Next, in step S 15 , the loading unit  21  loads the Java part  30 B of the device driver  30 . In addition, at a time of loading the Java part  306 , the loading unit  21  acquires the API information in which a class name and a method name defined in the Java part  30 B are associated with a corresponding Java object, thereby storing the API information in such a API table  25  illustrated in, for example,  FIG. 6 . 
         [0088]    Next, in step S 16 , the loading unit  21  imports the JavaScript part  30 A of the device driver  30 . 
         [0089]    Next, in step S 17 , the app  45  determines whether or not a control instruction for the peripheral device  50  is received. In a case where no control instruction is received, the determination in the present step is repeated until a control instruction is received, and in a case where the control instruction is received, the processing makes a transition to step S 18 . 
         [0090]    In step S 18 , the app  45  calls an API of the JavaScript part  30 A, which corresponds to the control instruction. Next, in step S 19 , the JavaScript part  30 A converts the API called in response to the control instruction, into a general-purpose API including information of a class name, a method name, an argument, and a callback function that correspond to the control instruction, and the JavaScript part  30 A delivers the general-purpose API to the access unit  22  via the coordination unit  34 . 
         [0091]    Next, in step S 20 , the access unit  22  extracts the class name and the method name from the general-purpose API and references the API table  25 , thereby acquiring a corresponding Java object name. In addition, the access unit  22  calls an API of the Java part  30 B, used for accessing a Java object indicated by the acquired Java object name. In accordance with the Java object corresponding to the called API, the Java part  30 B notifies the device information exchange unit  38  of information for controlling the peripheral device  50 . 
         [0092]    Next, in step S 21 , in accordance with the information given notice of by the Java part  30 B, the device information exchange unit  38  accesses the peripheral device  50  via the communication unit  39  and exchanges information with the peripheral device  50 . Next, in step S 22 , the device information exchange unit  38  replies to the API called from the Java part  30 B, with information acquired from the peripheral device  50 . 
         [0093]    Next, in step S 23 , the Java part  30 B delivers, to the coordination unit  34 , the information with which the device information exchange unit  38  replies. The coordination unit  34  returns, to the JavaScript part  30 A, the received response as an argument of the callback function included in the general-purpose API. 
         [0094]    Next, in step S 24 , the JavaScript part  30 A replies, with the received response, to the app  45  that called the API of the JavaScript part  30 A. Next, in step S 25 , the app  45  delivers the received response to the UI control unit  40 , the UI control unit  40  controls a UI so that information corresponding to the response is displayed, and the information processing routine finishes. 
         [0095]      FIG. 9  schematically illustrates a flow of the above-mentioned information processing routine. If the device driver  30  of the peripheral device  50  for which the app  45  make an access request is downloaded, the loading unit  21  loads the Java part  30 B of the device driver  30  (( 1 ) in  FIG. 9 ). At this time, the loading unit  21  acquires and stores the API information from the Java part  30 B and in the API table  25  (( 2 ) in  FIG. 9 ). In addition, the loading unit  21  imports the JavaScript part  30 A of the device driver  30  (( 3 ) in  FIG. 9 ). 
         [0096]    In addition, if the app  45  issues a control instruction for the peripheral device  50 , APIs of the JavaScript part  30 A, which correspond to the control instruction, are called (( 4 )  FIG. 9 ). The called APIs are converted into a general-purpose API and are delivered to the access unit  22  (( 5 )  FIG. 9 ). Based on the general-purpose API and the API information of the API table  25 , the access unit  22  calls APIs of the Java part  30 B (( 6 )  FIG. 9 ). In addition, the Java part  30 B controls the peripheral device  50  (( 7 ) in  FIG. 9 ). 
         [0097]    Note that the device driver (the JavaScript part  30 A and the Java part  30 B) made redundant may be unloaded on a case-by-case basis. At a timing when, for example, the JavaScript part  30 A makes a request, the Java part  30 B may be unloaded. In addition, at a timing such as an app termination time, the JavaScript part  30 A may be unloaded, and at a timing when the JavaScript part  30 A is unloaded, the Java part  30 B may be unloaded. 
         [0098]    The unloading of the Java part  30 B may be realized by releasing a Java object corresponding to a class of the loaded Java part  30 B. Note that in order for the app  45  or the JavaScript part  30 A to control the unloading of the Java part  30 B, an API, which is used for the unloading and which is able to call the JavaScript part  30 A, is prepared in the runtime in advance. 
         [0099]    In this way, by arbitrarily unloading the loaded device driver  30 , it is possible to reduce used resources such as a memory and so forth, and it is possible to inhibit the JavaScript part  30 A or the Java part  30 B from being wrongly called. 
         [0100]    As described above, according to the information processing system  10  related to the first embodiment, in a case where, in the mobile terminal  20 , the app  45  utilizes the peripheral device  50 , the device driver  30  of the peripheral device  50  only has to be downloaded and loaded. In addition, since including the first module (the JavaScript part  30 A) described by using the web technology and the second module (the Java part  30 B) described by using the native language, the device driver  30  may be applied to the hybrid application. Note that coordination between the first module and the second module may be realized by associating the API information acquired from the second module and an API called from the first module with each other. In other words, it is possible to dynamically replace device drivers to be used by the hybrid application to utilize a peripheral device. In addition, since it becomes possible to dynamically replace device drivers, it becomes possible to access various devices without updating an app. 
         [0101]    In addition, a complicated program is described in a device driver in some cases. In addition, a device driver for a native app is usually described by a native language. Therefore, it takes a lot of effort to create a device driver for the hybrid app by diverting the device driver for a native app. In a case of only shooting a photograph in coordination with, for example, a camera device, a simple program only used for calling an API for shooting only has to be described as a device driver. However, in a case of providing, as a driver, a program for recognizing and acquiring a character string from a shot photograph (an OCR function), it is desirable to describe a complicated program, and it is difficult to divert a device driver for a native app. 
         [0102]    However, in a case of a device driver including the first module described by using a web technology and the second module described by using a native language in such a way as in the present embodiment, it becomes easy to divert a device driver for a native app. 
         [0103]    In addition, in a case where a device driver on a native side is defined as a general-purpose device driver in such a way as in the related art, it is difficult to replace the general-purpose device driver. Therefore, a content described in a device driver of a web technology increases. A case where an app utilizes information, related to an operation of a person and detected based on, for example, the value of an acceleration sensor, will be considered. In a case where a native side is a general-purpose device driver, it is difficult for the general-purpose device driver to perform processing corresponding to an app. Therefore, the sensor value acquired from the acceleration sensor turns out to be handed over to a device driver on a web technology side without change. In addition, it is conceivable that, in the device driver on the web technology, a device driver to perform such an operation as analyzing the sensor value, determining the operation of the person, and returning a determination result to the app is created. 
         [0104]    However, a program described by using a script language serving as the web technology operates at a slower rate. In particular, it is difficult to subject the JavaScript to optimum just in time (JIT) compilation. Therefore, while various speed-up techniques are developed, the JavaScript operates at a rate slower than in a case of compiling the Java or the C language. Accordingly, in a case where the number of processing operations based on the JavaScript is larger, a processing time of the entire device driver becomes longer than in a case where the number of processing operations based on the Java or the C language is larger. In addition, it takes time to perform communication between the web technology and the native language. Therefore, in a case where the native language hands over all acquired sensor values to the web technology, the time taken to perform the communication becomes longer than in a case where a determination result obtained by analyzing sensor values and performing determination is only handed over. 
         [0105]    On the other hand, in a case of the present embodiment, it is possible to replace the device driver  30 . Therefore, in accordance with the peripheral device  50  to be used, it is possible to use a device driver to perform a large number of processing operations in the Java part. Accordingly, it is possible to accelerate the processing speed of the device driver. 
         [0106]    Note that while, in the first embodiment, a case where first the Java part is loaded and the JavaScript part is imported after that is described, there is no limitation thereto. 
         [0107]    Like the device driver  30  illustrated in, for example,  FIG. 5 , a program for calling the lava part  30 B is described in the JavaScript part  30 A in advance, and first this JavaScript part  30 A is imported on a priority basis. In addition, based on a request from the JavaScript part  30 A, the Java part  30 B may be loaded. In addition, the JavaScript part  30 A is imported first, and by being triggered by calling of an API of the Java part  30 B, performed by the access unit  22 , the Java part  30 B may be loaded. By doing this, it is possible to inhibit the Java part  30 B from being undesirably loaded. 
       Second Embodiment 
       [0108]    Next, a second embodiment will be described. Note that regarding an information processing system according to the second embodiment, the same symbol is assigned to the same portion as that of the information processing system  10  according to the first embodiment, and the detailed description thereof will be omitted. 
         [0109]    As illustrated in  FIG. 1 , an information processing system  210  according to the second embodiment includes a mobile terminal  220 , the peripheral device  50 , the device driver distribution server  52 , and the app distribution server  54 . 
         [0110]      FIG. 10  illustrates a schematic configuration of the mobile terminal  220 . The mobile terminal  220  includes a generation unit  23  in addition to the individual functional units of the mobile terminal  20  according to the first embodiment and includes a loading unit  221  in place of the loading unit  21  of the mobile terminal  20  according to the first embodiment. 
         [0111]    The loading unit  221  is different from the loading unit  21  in the first embodiment in that the loading unit  221  imports not the JavaScript part  30 A stored in the driver storage unit  37  but the JavaScript part  30 A generated in the generation unit  23  to be described later. 
         [0112]    Since, as described above, a program described by using the native language operates at a rate faster than a program described by using the script language, it is desirable that the description amount of the JavaScript part  30 A is as small as possible. In the JavaScript part  30 A, simple conversion processing for calling, for example, the Java part  30 B only has to be described. Therefore, in the second embodiment, the generation unit  23  generates the JavaScript part  30 A in which the simple conversion processing is described. 
         [0113]    Specifically, the generation unit  23  generates the JavaScript part  30 A in which a method name of the API information stored in the API table  25  is an API of the JavaScript part  30 A, which is to be called by the app  45 . In addition, in a case where there is an argument in the method name of the API information, in other words, an API to be called from the Java part  30 B, information of the argument is added to the API of the JavaScript part  30 A. Like the argument, at a time of storing the API information in the API table  25 , information desirable for generating the JavaScript part  30 A is stored along therewith. 
         [0114]    As illustrated below, the generation unit  23  is able to generate, for example, the JavaScript part  30 A from the Java part  30 B. 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 &lt;Java Part 30B&gt; 
               
               
                 Class SensorNativeDriver {static public void func1(int value1) {...}} 
               
               
                 &lt;Generated JavaScript Part 30A&gt; 
               
               
                   function func1(value1) 
               
               
                 {this.device.callNative(“com.fjl.nativedriver.dex/SensorNativeDriver”, 
               
               
                 “func1”,[value1], function( ){ }, function( ) { });} 
               
               
                   
               
             
          
         
       
     
         [0115]    Note that in order to limit a method of the Java part  30 B, accessible from the JavaScript part  30 A, an annotation may be assigned to a definition part of a method in the Java part  30 B. As illustrated below, for example, an annotation (“@JSMethod” in the following example) is assigned in advance to a method of the Java part  30 B, accessible from the JavaScript part  30 A. 
         [0116]    @JSMethodpublic void getSystolic (JSONObject json, JavaDriverListener driverListener) { } 
         [0117]    The generation unit  23  determines that a method to which the annotation is assigned is a method accessible from the JavaScript part  30 A, and the generation unit  23  describes, in the JavaScript part  30 A, an API for calling the method. In this case, regarding a method to which an annotation is assigned, when the loading unit  221  stores the API information in the API table  25 , the annotation is stored in the API table  25  along therewith. Based on the API information to which an annotation is assigned in the API table  25 , the generation unit  23  only has to generate the JavaScript part  30 A. 
         [0118]    The mobile terminal  220  may be realized by, for example, the computer  60  illustrated in  FIG. 7 . In the storage unit  63  in the computer  60 , an Information processing program  270  for causing the computer  60  to function as the mobile terminal  220  is stored. The CPU  61  reads and deploys the information processing program  270  from the storage unit  63  and in the memory  62  and sequentially executes processes included in the information processing program  270 . The information processing program  270  includes a loading process  271 , the access process  72 , a generation process  73 , and the information processing process  80 . 
         [0119]    The CPU  61  executes the loading process  271 , thereby operating as the loading unit  221  illustrated in  FIG. 10 . In addition, the CPU  61  executes the generation process  73 , thereby operating as the generation unit  23  illustrated in  FIG. 10 . The other processes are the same as those of the information processing program  70  in the first embodiment. From this, the computer  60  that executes the information processing program  270  turns out to function as the mobile terminal  220 . 
         [0120]    Next, regarding operations of the information processing system  210  according to the second embodiment, points different from the first embodiment will be described. 
         [0121]    Before step S 16  in the information processing routine illustrated in  FIG. 8 , the generation unit  23  references the API table  25 , thereby generating the JavaScript part  30 A. In addition, in step S 16 , the loading unit  221  imports not the device driver  30  stored in the driver storage unit  37  but the JavaScript part  30 A generated by the generation unit  23 . 
         [0122]    Since processing operations in subsequent stages are the same regardless of the JavaScript part  30 A generated from the Java part  30 B or the JavaScript part  30 A downloaded along with the Java part  30 B, the descriptions thereof will be omitted. 
         [0123]    As described above, according to the information processing system  210  related to the second embodiment, based on the second module described by using the native language, the first module of the web technology is automatically generated. Therefore, since the second module only has to be prepared as a device driver, it is possible to make development of a device driver efficient. 
         [0124]    Note that the JavaScript part  30 A generated in the second embodiment may be stored and the stored JavaScript part  30 A may be imported in a case where the same Java part  30 B is loaded again. In this case, the class name of the Java part  30 B, used at the time of generating the JavaScript part  30 A, is stored while being associated with the generated JavaScript part  30 A. In addition, it is desirable that the JavaScript part  30 A corresponding to the class name defined in the loaded Java part  30 B is searched for within the stored JavaScript part  30 A and is used. From this, in a case where the Java part  30 B of the same device driver  30  is loaded, the JavaScript part  30 A does not have to be generated again. Therefore, it is possible to speed up importing of the JavaScript part  30 A. 
         [0125]    In addition, there is a case where the version of the Java part  30 B is upgraded. Therefore, in order to respond to this, it is desirable that, as illustrated below, for example, a class name of the Java part  30 B and version information of that class are used in combination. {“Java_driver”: “driver.jar”, “java_driver_class”: “com.fujitsu.jp.driver.BloodPressure”,“version”: “1.01” } 
         [0126]    Furthermore, in a case where an API defined in the Java part  30 B of the different device driver  30  has the same function, a method for absorbing a difference between these APIs may be implemented. In a case where device vendors are different even if the type of the peripheral device  50  is, for example, the same sphygmomanometer, the device drivers  30  different from each other are created. In this case, methods of the Java parts  30 B Included in the respective device drivers  30  are defined in forms different from each other in some cases. Therefore, such an API correspondence table as illustrated in, for example,  FIG. 11  is created in advance. 
         [0127]    An example of this API correspondence table indicates correspondence relationships of APIs of device drivers corresponding to respective device IDs=0x12340001 and 0x23451234, regarding the peripheral device  50  indicated by a service UUID=0x1810. More specifically, it indicates that an API of the JavaScript part  30 A, used for accessing a method “getSystolic” of the Java part  30 B of the device ID=0x12340001 is an API1. In addition, it is assumed that in the Java part  30 B of the device ID=0x23451234, a method “getBloodPressureSystolic” has the same function as that of the above-mentioned “getSystolic”. In this case, in the same way as “getSystolic” of the device ID=0x12340001, “getBloodPressureSystolic” is associated with the API1 of the JavaScript part  30 A. Based on this information, in each of a case of the device ID=0x12340001 and a case of the device ID=0x23451234, it is possible to generate the JavaScript part  30 A so as to enable an equivalent method of the Java part  30 B to be called based on the same API1. In a case where the Java part  30 B of, for example, the device ID=0x23451234 is loaded, the generation unit  23  is able to generate the JavaScript part  30 A as follows. 
         [0128]    function getSystolic(success, failure, unit) {cordova.exec(success, failure, “JavaDriver”, “call_Java”, [“getBloodPressureSystolic”, unit]);} 
         [0129]    From this, it is possible to generate the JavaScript part  30 A to absorb a difference between methods defined in the respective Java parts  30 B so that even the Java parts  30 B having different APIs are accessible by the app  45  by using the same API. 
       Third Embodiment 
       [0130]    Next, a third embodiment will be described. Note that regarding an information processing system according to the third embodiment, the same symbol is assigned to the same portion as that of the information processing system  10  according to the first embodiment, and the detailed description thereof will be omitted. 
         [0131]    As illustrated in  FIG. 1 , an information processing system  310  according to the third embodiment includes a mobile terminal  320 , the peripheral device  50 , the device driver distribution server  52 , and the app distribution server  54 . 
         [0132]      FIG. 12  illustrates a schematic configuration of the mobile terminal  320 . The mobile terminal  320  includes a switching unit  24  in addition to the individual functional units of the mobile terminal  20  according to the first embodiment and includes a loading unit  321  in place of the loading unit  21  of the mobile terminal  20  according to the first embodiment. 
         [0133]    Here, within OSs to be utilized by the mobile terminal  320 , there is an OS in which an app to operate on the OS is described only by using a web technology in such a manner as, for example, the Firefox (registered trademark) OS. In this case, functions provided by the OS are provided as APIs accessible by the web technology. Accordingly, a device driver is able to be described only by using the web technology. Therefore, in a case where the OS is, for example, the Android (registered trademark), the JavaScript part  30 A and the Java part  30 B are used as a device driver, and in a case of the Firefox OS, only the JavaScript part  30 A is used as a device driver. Therefore, in the third embodiment, a device driver to be used is switched depending on an OS mounted in the mobile terminal  320 . 
         [0134]    In the same way as the loading unit  21  according to the first embodiment, the loading unit  321  loads the Java part  30 B of the device driver  30  stored in the driver storage unit  37  and imports the JavaScript part  30 A. At this time, in a case where the OS mounted in the mobile terminal  320  performs entire processing by using the web technology in such a manner as, for example, the Firefox OS, in other words, in a case where the native language is not recognizable, the Java part  30 B is not loaded. The loading unit  321  notifies the switching unit  24  of information indicating whether or not the loading of the Java part  30 B is completed. 
         [0135]    Based on the notification from the loading unit  321 , the switching unit  24  switches between directly accessing the device information exchange unit  38  from the JavaScript part  30 A and calling the Java part  30 B in the same way as in the first embodiment. Specifically, the switching unit  24  provides an API accessible from the JavaScript part  30 A, and at a time when this API is accessed from the JavaScript part  30 A, the switching unit  24  returns information indicating whether or not the Java part  30 B exists. Based on the response from the API of the switching unit  24 , the JavaScript part  30 A is able to switch an access destination. Specifically, in a case where the Java part  30 B exists, the JavaScript part  30 A converts a called API into a general-purpose API and delivers the general-purpose API to the access unit  22 , in the same way as in the first embodiment. In a case where no Java part  30 B exists, the JavaScript part  30 A directly delivers, to the device information exchange unit  38 , a control instruction indicated by the called API. 
         [0136]    The mobile terminal  320  may be realized by, for example, the computer  60  illustrated in  FIG. 7 . In the storage unit  63  in the computer  60 , an information processing program  370  for causing the computer  60  to function as the mobile terminal  320  is stored. The CPU  61  reads and deploys the information processing program  370  from the storage unit  63  and in the memory  62  and sequentially executes processes included in the information processing program  370 . The information processing program  70  includes a loading process  371 , the access process  72 , a switching process  74 , and the information processing process  80 . 
         [0137]    The CPU  61  executes the loading process  371 , thereby operating as the loading unit  321  illustrated in  FIG. 12 . In addition, the CPU  61  executes the switching process  74 , thereby operating as the switching unit  24  illustrated in  FIG. 12 . The other processes are the same as those of the information processing program  70  in the first embodiment. From this, the computer  60  that executes the information processing program  370  turns out to function as the mobile terminal  320 . 
         [0138]    Next, operations of the information processing system  310  according to the third embodiment will be described. In the third embodiment, an information processing routine illustrated in  FIG. 13  is executed in the mobile terminal  320 . Note that, in the information processing routine in the third embodiment, the same symbol is assigned to the same processing operation as that of the information processing routine ( FIG. 8 ) according to the first embodiment and the detailed description thereof will be omitted. 
         [0139]    In step S 15 , in a case where the OS is able to recognize the Java, the loading unit  321  loads the Java part  30 B and stores the API information in the API table  25 . On the other hand, in a case where the OS is not able to recognize the Java, the Java part  30 B is not loaded. 
         [0140]    Next, in step S 311 , the switching unit  24  is notified of whether or not the loading unit  321  completes loading of the Java part  30 B in the above-mentioned step S 15 . Next, in step S 312  after steps S 16  to S 18 , the JavaScript part  30 A accesses the switching unit  24 . Based on a loading result of the Java part  30 B, given notice of by the loading unit  321  in the above-mentioned step S 311 , the switching unit  24  returns, to the JavaScript part  30 A, information of whether or not the Java part  30 B exists. Based on the response from the switching unit  24 , the JavaScript part  30 A determines whether or not the Java part  30 B exists. In a case where the Java part  30 B exists, the processing makes a transition to step S 313 , and access-via-Java-part processing is performed. The access-via-Java-part processing is the same processing as steps S 19  to S 23  in the information processing routine in the first embodiment. 
         [0141]    On the other hand, in a case where no Java part  30 B exists, the processing makes a transition to step S 314 , and the JavaScript part  30 A directly delivers, to the device information exchange unit  38 , a control instruction indicated by the called API. 
         [0142]    Next, in step S 24 , the JavaScript part  30 A receives a response from the coordination unit  34  or the device information exchange unit  38  and replies to an app that calls the API of the JavaScript part  30 A. In addition, in step S 25 , information corresponding to the response is displayed, and the information processing routine finishes. 
         [0143]    As described above, according to the information processing system  310  related to the third embodiment, depending whether or not the second module described by using the native language exists, a destination of an access from the first module described by using the web technology is switched. From this, in accordance with the OS mounted in the mobile terminal  320  that downloads the device driver, it is possible to adequately switch an operation. 
         [0144]    In addition, regardless of whether or not the second module operates, the first module (JavaScript part) operates in each of, for example, the Android, the iOS, and the Firefox OS. Therefore, since it is possible to commonalize the first module, one device driver  30  only has to be prepared independently of OSs. Accordingly, it is possible to make development of the device driver  30  efficient. 
         [0145]    Note that while a case where one device driver  30  is downloaded independently of OSs and a module to be used is switched between the first module and the second module at a time of utilizing the peripheral device  50  is described in the third embodiment, there is no limitation thereto. In accordance with an OS, a device driver to be downloaded may be switched. Specifically, at a time when the driver acquisition unit  36  downloads a device driver, OS information is transmitted to the device driver distribution server  52 . The device driver distribution server  52  distributes a device driver corresponding to this OS Information. From this, it is possible to perform an operation corresponding to the OS without switching an operation at a time of utilizing the peripheral device  50 . 
         [0146]    In a case where the OS is, for example, the Android, such an information file illustrated as follows is transmitted and the device driver  30  including the JavaScript part  30 A and the Java part  30 B is distributed, in the same way as in the above-mentioned embodiments. 
         [0147]    {“java_driver”: “driver.jar”, “java_driver_class”: “com.fujitsu.jp.driver.BloodPressure”, “js_driver”: “driverAndroidOS.js” } 
         [0148]    In addition, in a case where the OS is the Firefox OS, such an Information file illustrated as follows is transmitted, and a device driver of only the JavaScript part  30 A is distributed. 
         [0149]    {“js_driver”: “driverFirefoxOS.js” } 
         [0150]    In addition, information of both files of the Java part  30 B and the JavaScript part  30 A may be included in the information file in advance, and at a time of creating a URL for acquiring a device driver, a URL for acquiring only a desirable device driver may be created. 
       Fourth Embodiment 
       [0151]    Next, a fourth embodiment will be described. Note that regarding an information processing system according to the fourth embodiment, the same symbol is assigned to the same portion as that of the information processing system  10  according to the first embodiment, and the detailed description thereof will be omitted. 
         [0152]    As illustrated in  FIG. 1 , an information processing system  410  according to the fourth embodiment includes a mobile terminal  420 , the peripheral device  50 , the device driver distribution server  52 , and the app distribution server  54 . 
         [0153]      FIG. 14  illustrates a schematic configuration of the mobile terminal  420 . The mobile terminal  420  includes a loading unit  421  in place of the loading unit  21  of the mobile terminal  20  according to the first embodiment and includes an access unit  422  in place of the access unit  22 . 
         [0154]    In the same way as the loading unit  21  according to the first embodiment, the loading unit  421  loads the Java part  30 B of the device driver  30  stored in the driver storage unit  37  and imports the JavaScript part  30 A. In addition, at a time of importing the JavaScript part  30 A, the loading unit  421  sets a variable such as, for example, var secret=abcdef123456. Furthermore, as illustrated as follows, the loading unit  421  describes in the JavaScript part  30 A so that the set variable is included, as an argument, in an API for calling the Java part  30 B, for example. 
         [0155]    function getSystolic(success, failure, unit) {cordova.exec(success, failure, “JavaDriver”, “call_java”, [“getSystolic”, secret, unit]);} 
         [0156]    In addition, the loading unit  421  notifies the access unit  422  of the set variable. 
         [0157]    The access unit  422  determines whether or not a variable included, as an argument, in a general-purpose API delivered by the JavaScript part  30 A and the variable given notice of by the loading unit  421  coincide with each other. In a case where the variables coincide with each other, the access unit  422  calls the Java part  30 B, and in a case where the variables do not coincide with each other, the access unit  422  returns an error to the JavaScript part  30 A. 
         [0158]    The mobile terminal  420  may be realized by, for example, the computer  60  illustrated in  FIG. 7 . In the storage unit  63  in the computer  60 , an Information processing program  470  for causing the computer  60  to function as the mobile terminal  420  is stored. The CPU  61  reads and deploys the information processing program  470  from the storage unit  63  and in the memory  62  and sequentially executes processes included in the information processing program  470 . The information processing program  470  includes a loading process  471 , an access process  472 , and the information processing process  80 . 
         [0159]    The CPU  61  executes the loading process  471 , thereby operating as the loading unit  421  illustrated in  FIG. 14 . In addition, the CPU  61  executes the access process  472 , thereby operating as the access unit  422  illustrated in  FIG. 14 . The other processes are the same as those of the information processing program  70  in the first embodiment. From this, the computer  60  that executes the information processing program  470  turns out to function as the mobile terminal  420 . 
         [0160]    Next, operations of the information processing system  410  according to the fourth embodiment will be described. In the fourth embodiment, an information processing routine illustrated in  FIG. 15  is executed in the mobile terminal  420 . Note that, in the information processing routine in the fourth embodiment, the same symbol is assigned to the same processing operation as that of the information processing routine ( FIG. 8 ) according to the first embodiment and the detailed description thereof will be omitted. 
         [0161]    In step S 411  subsequent to step S 15 , the loading unit  421  sets a variable and notifies the access unit  422  of the set variable. 
         [0162]    Next, in step S 412 , the loading unit  421  imports the JavaScript part  30 A and describes in the JavaScript part  30 A so that the set variable is included, as an argument, in an API for calling the Java part  30 B. 
         [0163]    Next, in subsequent step S 413  after steps S 17  and S 18 , the variable set in the above-mentioned step S 411  is caused to be included as an argument of an API of the JavaScript part  30 A called by the app  45 , and the API of the JavaScript part  30 A is converted into a general-purpose API and is delivered to the access unit  422 . 
         [0164]    Next, in step S 414 , the access unit  422  determines whether or not a variable included, as an argument, in the general-purpose API delivered from the JavaScript part  30 A and the variable given notice of by the loading unit  421  in the above-mentioned step S 411  coincide with each other. In a case where the variables coincide with each other, steps S 20  to S 25  are executed in the same way as in the first embodiment. On the other hand, in a case where the variables do not coincide with each other, the processing makes a transition to step S 415 , and the access unit  422  returns an error to the app  45  via the JavaScript part  30 A and terminates the information processing routine. 
         [0165]    As described above, according to the information processing system  410  related to the fourth embodiment, the first module described by using the web technology and the access unit  422  are each caused to have the same variable. In addition, in a case where the first module calls the second module, it is determined, based on whether or not a variable the first module has and a variable the access unit  422  has coincide with each other, whether or not the second module is permitted to be accessed. From this, it is possible to inhibit the second module from being called by a module other than the first module, and security is enhanced. 
       Fifth Embodiment 
       [0166]    Next, a fifth embodiment will be described. Note that regarding an Information processing system according to the fifth embodiment, the same symbol is assigned to the same portion as that of the information processing system  10  according to the first embodiment, and the detailed description thereof will be omitted. 
         [0167]    As illustrated in  FIG. 1 , an information processing system  510  according to the fifth embodiment includes a mobile terminal  520 , the peripheral device  50 , the device driver distribution server  52 , and the app distribution server  54 . 
         [0168]    Depending on an OS mounted in the mobile terminal  520 , native languages are used in some cases. In a case of, for example, the Android, the C language is able to be used as a native language in addition to the Java. Therefore, in the fifth embodiment, a configuration in which a device driver includes the first module described by using the JavaScript, the second module described by using the Java, and a third module described by using the C language is adopted. 
         [0169]      FIG. 16  illustrates a schematic configuration of the mobile terminal  520 . The mobile terminal  520  includes a loading unit  521  in place of the loading unit  21  of the mobile terminal  20  according to the first embodiment and includes an access unit  522  in place of the access unit  22 . In addition, the mobile terminal  520  includes a driver acquisition unit  536  in place of the driver acquisition unit  36  of the mobile terminal  20  according to the first embodiment. 
         [0170]    As described above, in the fifth embodiment, the device driver including the 3 modules is used. Therefore, the driver acquisition unit  536  acquires, from the device driver distribution server  52 , an information file extended as follows, for example. In addition, in the same way as the JavaScript part  30 A and the Java part  30 B, the driver acquisition unit  536  downloads a file of a C language part  30 C, based on information of c_driver. 
         [0171]    {“java_driver”: “driver.jar”, “java_driver_class”: “com.fujitsu.jp.driver.BloodPressure”, 
         [0172]    “js_driver”: “driver.js”, 
         [0173]    “c_driver”:“driver.lib” } 
         [0174]    In the same way as the loading unit  21  according to the first embodiment, the loading unit  521  loads the Java part  30 B of the device driver  30  stored in the driver storage unit  37  and imports the JavaScript part  30 A. In addition, the loading unit  521  loads the C language part  30 C of the device driver  30  stored in the driver storage unit  37 . Furthermore, at a time of loading the C language part  30 C, the loading unit  521  acquires and stores the API information of the C language part  30 C, in an API table  525 . In the same way as acquisition of the API information of the Java part  30 B in the first embodiment, it is possible to acquire the API information of the C language part  30 C. The API table  525  includes such a table illustrated in  FIG. 6 , in which the API information of the Java part  30 B is stored, and a table in which the API information of the C language part  30 C having the same format is stored. The API information of the Java part  30 B includes API information for calling the C language part  30 C. 
         [0175]    Based on a general-purpose API received from the JavaScript part  30 A and the API information of the Java part  30 B of the API table  525 , the access unit  522  calls an API of the Java part  30 B. The Java part  30 B delivers the called API to the access unit  522 . Based on the API received from the Java part  30 B and the API information of the C language part  30 C of the API table  525 , the access unit  522  calls an API of the C language part  30 C. In accordance with the called API, the C language part  30 C notifies the device information exchange unit  38  of information for controlling the peripheral device  50 . 
         [0176]    The mobile terminal  520  may be realized by, for example, the computer  60  illustrated in  FIG. 7 . In the storage unit  63  in the computer  60 , an information processing program  570  for causing the computer  60  to function as the mobile terminal  520  is stored. The CPU  61  reads and deploys the information processing program  570  from the storage unit  63  and in the memory  62  and sequentially executes processes included in the information processing program  570 . The information processing program  570  includes a loading process  571 , an access process  572 , and the information processing process  80 . 
         [0177]    The CPU  61  executes the loading process  571 , thereby operating as the loading unit  521  illustrated in  FIG. 16 . In addition, the CPU  61  executes the access process  572 , thereby operating as the access unit  522  illustrated in  FIG. 16 . The other processes are the same as those of the information processing program  70  in the first embodiment. From this, the computer  60  that executes the information processing program  570  turns out to function as the mobile terminal  520 . 
         [0178]    Next, operations of the information processing system  510  according to the fifth embodiment will be described. In the fifth embodiment, an information processing routine illustrated in  FIG. 17  is executed in the mobile terminal  520 . Note that, in the information processing routine in the fifth embodiment, the same symbol is assigned to the same processing operation as that of the information processing routine ( FIG. 8 ) according to the first embodiment and the detailed description thereof will be omitted. 
         [0179]    In step S 511  subsequent to step S 14 , the loading unit  521  loads the Java part  30 B and acquires and stores the API Information of the Java part  30 B, in the API table  525 . In addition, the loading unit  521  loads the C language part  30 C and acquires and stores the API information of the C language part  30 C, in the API table  525 . 
         [0180]    Next, in subsequent step S 512  after steps S 16  to S 19 , the access unit  522  calls the API of the Java part  30 B, based on a general-purpose API and the API table  525 . Next, in step S 513 , based on the API called from the Java part  30 B and the API information of the C language part  30 C of the API table  525 , the access unit  522  calls the API of the C language part  30 C. In addition, in accordance with the called API, the C language part  30 C notifies the device information exchange unit  38  of information for controlling the peripheral device  50 . 
         [0181]    Next, in step S 21 , the device information exchange unit  38  accesses the peripheral device  50 . Next, in step S 514 , the device information exchange unit  38  replies to the API called from the C language part  30 C, with information acquired from the peripheral device  50 . Next, in step S 515 , the C language part  30 C replies to the API called from the Java part  30 B, with information acquired from the peripheral device  50 . After that, in the same way as in the first embodiment, the processing operations in steps S 23  to S 25  are performed, and the information processing routine finishes. 
         [0182]    As described above, according to the information processing system  510  related to the fifth embodiment, in a case where the OS mounted in the mobile terminal  520  is able to use native languages, a device driver including modules described by using various types of native language is used. From this, a program, which is described by using, for example, the C language and whose operation is faster than that of a program described by using the Java, is used, thereby enabling to speed up processing of a device driver. In addition, it is possible to divert, to the C language part  30 C of the device driver, a device driver described by using, for example, the previously developed C language, and it is possible to make development of the device driver efficient. 
         [0183]    Note that in each of the above-mentioned embodiments, a case where the first module is defined as a module described by using the JavaScript and the second module is defined as a module described by using the Java is mainly explained. In addition, in the fifth embodiment, a case where the third module is defined as a module described by using the C language is explained. However, the individual modules are not limited to a case of being described by using these languages. The first module only has to be a module described by using a language recognizable by an application, and each of the second module and the third module only has to be described by using a language recognizable by a peripheral device or an OS to control the peripheral device. In particular, the first module is described by using a web technology, and each of the second module and the third module is described by using a native language, thereby being able to be applied to a hybrid app. From this, a web technology having a large number of developers is available, and a device driver of a previously developed native language is able to be utilized. 
         [0184]    Note that, in the above-mentioned embodiments, modes in which the respective information processing programs are preliminarily stored (installed) in the storage unit  63  are described, there is no limitation thereto. A program according to the disclosed technology may be provided in a form of being recorded in a recording medium such as a CD-ROM, a DVD-ROM, or a USB memory. 
         [0185]    All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions, nor does the organization of such examples in the specification relate to a showing of the superiority and inferiority of the invention. Although the embodiments of the present invention have been described in detail, it should be understood that the various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the invention.