WO2009062396A1 - Procédé d'accès à des ressources et système d'accès à des ressources - Google Patents

Procédé d'accès à des ressources et système d'accès à des ressources Download PDF

Info

Publication number
WO2009062396A1
WO2009062396A1 PCT/CN2008/001824 CN2008001824W WO2009062396A1 WO 2009062396 A1 WO2009062396 A1 WO 2009062396A1 CN 2008001824 W CN2008001824 W CN 2008001824W WO 2009062396 A1 WO2009062396 A1 WO 2009062396A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
user
external
requested
access
Prior art date
Application number
PCT/CN2008/001824
Other languages
English (en)
French (fr)
Inventor
Chunmei Zhu
Qingxiang Zeng
Rui Hou
Wei Wu
Baoping Cheng
Xin Zhang
Chuan Yu
Original Assignee
China Mobile Communications Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN2007101771251A external-priority patent/CN101431713B/zh
Priority claimed from CN200810115488A external-priority patent/CN101616132B/zh
Application filed by China Mobile Communications Corporation filed Critical China Mobile Communications Corporation
Publication of WO2009062396A1 publication Critical patent/WO2009062396A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a resource access method and a resource access system. Background technique
  • any function plug-in (such as media player) developed on a mobile terminal must strictly follow the plug-in implementation mechanism of different operating systems and browsers.
  • the inventor finds that when using the existing technology to carry out specific services on the mobile terminal, it is necessary to adapt to different operating systems and browsers, the development process is complicated, the development cycle is long, and the service function modules can be reused. Poor performance and low scalability.
  • the mobile terminal can only access the internal resource and the external resource in different manners, and the user operation is complicated and the experience is poor.
  • the client of the user equipment generally includes multiple applications (such as a browser, Fetion, Email, etc.), and when one of the applications is to be launched, the corresponding resources need to be obtained, for example, obtaining advertisement information.
  • applications such as a browser, Fetion, Email, etc.
  • the corresponding resources need to be obtained, for example, obtaining advertisement information.
  • various applications in the current client are acquiring resources, they are obtained from the network side server through the interface of the application itself. Due to the diversity of applications, the application obtains resources from the network side server through the respective interfaces.
  • Complex implementation Moreover, the network side server needs to provide resources for multiple applications in the client, so the network side server is required to have multiple interfaces for interacting with multiple applications, resulting in a complicated interface of the network side server.
  • the embodiments of the present invention provide a resource access method and a resource access system, which are used to implement unified access to internal resources and external resources, and solve the problem that the process of acquiring resources by existing clients is complicated and the port resources are occupied.
  • An embodiment of the present invention provides a resource access method, where the method includes:
  • the resource access request message sent by the user through the client application is received by the unified interface, where the request message includes resource identification information, where the resource identifier information indicates that the resource requested by the user is a local resource or an external resource;
  • the embodiment of the invention further provides a resource access system, including a mobile terminal and an external network server;
  • the mobile terminal includes a message distribution module, a browser engine and an internal server;
  • a message distribution module configured to receive a resource access request message sent by the user through the client application, and forward the resource access request message to an internal server or a browser engine;
  • the browser engine is configured to obtain the resource identification information included in the resource access request message, and determine, according to the obtained resource identification information, that the resource requested by the user is a local resource or an external resource, and notify the determined result to the Internal server
  • the internal server is configured to obtain the resource identification information included in the resource access request message, and obtain, according to the obtained resource identification information, that the resource requested by the user is a local resource or an external resource, or is used to notify the user based on the browser engine As a result, know the resources that the user requested to access. It is a local resource or an external resource; it is also used to obtain the resource requested by the user, and provides the user with the resource requested by the user through the message distribution module.
  • the resource access method provided by the embodiment of the present invention receives the resource access request message sent by the user through the client application through the unified interface, and determines, according to the resource identification information included in the resource access request message, that the user requests to access the local resource, The local resource that is requested to be accessed is provided to the user through the unified interface.
  • the user requests to access the external resource according to the resource identification information included in the resource access request message the external resource requested to be accessed is provided to the user through the unified interface. Therefore, the unified access to the internal resource and the external resource can be realized through the unified resource access entry, and the resource access request sent by each application can be received through the unified interface, and the requested resource is provided through the unified interface.
  • the user who sends the resource access request saves the port resources and is technically simple to implement.
  • FIG. 1 is a flowchart of processing a resource access in an embodiment of the present invention
  • FIG. 2A, FIG. 2B, FIG. 2C are schematic diagrams showing the structure of a communication system according to an embodiment of the present invention
  • FIG. 2D and FIG. 2E are schematic diagrams showing the structure of a processing module according to an embodiment of the present invention
  • FIG. 3 is a schematic structural diagram of a specific example of a communication system according to an embodiment of the present invention
  • FIG. 4 is a schematic diagram of a data acquisition system according to an embodiment of the present invention
  • FIG. 5 is a flowchart 1 of a data acquisition method according to an embodiment of the present invention.
  • FIG. 6 is a flowchart 2 of a data acquisition method according to an embodiment of the present invention.
  • FIG. 7 is a structural diagram of a data acquiring apparatus according to an embodiment of the present invention. detailed description
  • Step 11 A mobile terminal receives a resource access request message sent by a user, where the request message includes resource identification information (for convenience of presentation, the following The resource identification information is simply referred to as identification information), the standard The information indicates that the resource requested by the user is a local resource or an external resource.
  • the user may send the resource access request in multiple manners. For example, the mobile terminal may receive the resource access request sent by the user directly through the HTTP mode, or may receive the resource access request sent by the user through the tag script.
  • Step 12 The mobile terminal determines, according to the identifier information, that the user requests to access the local resource or the external resource.
  • Step 13 When the mobile terminal determines that the user requests to access the local resource, the mobile terminal provides the user with the requested local resource according to different operating system types. When determining that the user requests to access the external resource, the mobile terminal provides the external resource requested by the user.
  • the tag script needs to be executed to obtain the identification information before performing steps 12 and 13; in this case, in step 12 and step 13,
  • the local resource or external resource requested by the user needs to be obtained by triggering an HTTP request or calling an application interface of the operating system.
  • step 13 before the mobile terminal provides the user with the requested local resource, the user may determine whether the user has the right to access the local resource, and when determining that the user has the right to access the local resource, according to different operating system types. Providing the local resource to the user; before the mobile terminal provides the external resource requested by the user, the user may determine whether the user has the right to access the external resource, and whether the address of the external resource is legal, and determine the user. When there is a right to access the external resource, and the address of the external resource is legal, the mobile terminal provides the external resource to the user.
  • the mobile terminal may obtain an external resource requested by the user from the external network. For example, after the mobile terminal sends the user's request to the external network, the external terminal receives the external resource returned by the external network according to the user request. After obtaining the external resource requested by the user, the mobile terminal may perform security detection on the external resource, and provide the external resource to the user when determining to pass the security detection.
  • the mobile terminal may determine whether the external resource is a specific resource according to whether the external resource includes a specific tag; When the resource is a specific resource, the external resource is provided to a browser supporting a specific resource for page processing and presented to the user; when it is determined that the external resource is not a specific resource, the external resource is provided to the general browser for page processing and Show it to the user.
  • the mobile terminal may obtain the local resource according to the user request, and after obtaining the local resource, provide the local resource to the browser supporting the specific resource for page processing and display to the user.
  • Providing the local terminal to the browser supporting the specific resource includes: the mobile terminal provides the local resource to a browser supporting a specific resource by using an HTTP method; or the mobile terminal notifies a browser supporting a specific resource to invoke the operating system The application interface that gets the local resource.
  • the user can subsequently operate the local resource, such as the user accessing the functions provided by the mobile terminal manufacturer, accessing the functions of the mobile terminal operating system itself, and accessing one or any combination of the third-party application software.
  • the mobile terminal When the mobile terminal provides the local resource to the browser supporting the specific resource by using the HTTP method, the user may perform operations such as application management, plug-in management, local resource search, etc.; the mobile terminal notifies the browser that supports the specific resource to invoke the application of the operating system.
  • Program interface when obtaining the local resource, the user can use any function provided by the mobile terminal, such as making a call, sending and receiving information, a camera, audio and video playback, and the like. Among them, the user can operate through the browser's user interface and submit the operation result. After receiving the operation result submitted by the user for operating the local resource, the mobile terminal may update the local resource according to the operation result.
  • the mobile terminal may record related information of a local resource or an external resource provided to the user; and subsequently, the user may be analyzed according to the recorded related information.
  • the structure of a mobile terminal is as shown in FIG. 2A, and includes: a receiving module 21, a determining module 22, and a processing module 23, wherein the receiving module 21 is configured to receive a resource access request message sent by the user, requesting The message includes the identifier information indicating that the resource requested by the user is a local resource or an external resource.
  • the determining module 22 is configured to determine, according to the identifier information, that the user requests to access the local resource or the external resource
  • the processing module 23 is configured to determine When a user requests access to a local resource, the user is provided with the requested local resource according to different operating system types; when it is determined that the user requests access to the external resource, the external resource requested by the user is provided to the user.
  • the mobile terminal shown in FIG. 2A may further include: a recording module 24, an analysis module 25, wherein the recording module 24 is configured to record related information of local resources or external resources provided to the user.
  • the analysis module 25 is configured to analyze the user's access behavior according to the recorded related information.
  • the mobile terminal shown in FIG. 2A may further include: an authentication module 26, configured to determine that the user has the right to access the local resource before providing the user with the requested local resource; And, before providing the user with the external resource requested for access, it is determined that the user has the right to access the external resource, and the address of the external resource is legal.
  • an authentication module 26 configured to determine that the user has the right to access the local resource before providing the user with the requested local resource. And, before providing the user with the external resource requested for access, it is determined that the user has the right to access the external resource, and the address of the external resource is legal.
  • the processing module 23 when the processing module 23 provides the user with the requested external resource, it can also be used to obtain external resources from the external network and provide it to the user.
  • the processing module 23 includes: a detecting unit 231, a first processing unit 232; wherein, the detecting unit 231 is configured to perform security detection on an external resource; and the first processing unit 232 is configured to Provide external resources to the user when determining to pass security detection.
  • the processing module 23 includes: a determining unit 233, a second processing unit 234, and a third processing unit 235.
  • the determining unit 233 is configured to determine whether a specific label is included in the external resource. Determining whether the external resource is a specific resource; the second processing unit 234 is configured to: when determining that the external resource is a specific resource, provide the external resource to a browser supporting the specific resource for page processing and display to the user; the third processing unit 235 , when used to determine that the external resource is not a specific resource, the external resource is provided to the universal browser for page processing and presented to the user.
  • the receiving module 21 is further configured to receive the resource access request sent by the user by using an HTTP method or a tag script.
  • the processing module 23 when the processing module 23 provides the user with the requested local resource, it can also be used to obtain the local resource, and provide the local resource to the browser supporting the specific resource for page processing and display to the user.
  • the processing module 23 when the processing module 23 provides the local resource to a browser supporting a specific resource, it may also be used to provide the local resource to a browser supporting a specific resource by using an HTTP method; or, the notification supports a specific The resource's browser calls the operating system's application interface to get The local resource.
  • the receiving module 21 can also be configured to receive the operation result submitted by the user for operating the local resource, and the processing module 23 can also be used to update local resources based on the results of the operation.
  • FIG. 3 which includes a browser, an internal server, and FIG. 3 also shows an external network and a local network.
  • Operating System which is the operating system on this device, can be Windows Mobile, Symbian or other operating system.
  • the browser, internal server and local operating system can all be integrated into the mobile terminal.
  • the main functions of the Browser include page rendering, script parsing execution, and so on.
  • the Browser can include:
  • the user interface (User Interface), that is, the browser interface that the user sees, to implement the function of the receiving module 21;
  • the message distribution module (Dispatcher) is configured to distribute the related request of the browser engine according to the corresponding configuration rule and the security policy, for example, according to the sending manner of the resource access request message, specifically, the resource access request message is HTTP
  • the resource access request message is HTTP
  • the resource access request message is forwarded to the internal server; when the resource access request message is sent by the tag script mode, the resource access request message is forwarded to the browser engine.
  • the determining module 22 and the processing module 23 including the functions performed by the determining unit 233, the second processing unit 234, and the third processing unit 235);
  • the Render Engine the browser engine, is used to implement the analysis of the tags, providing a scripting runtime environment to implement the functionality of the browser and browsers that support specific resources;
  • Render Engine includes the standard browser engine (Open Engine), which is the general browser engine; the extension engine, that is, the browser that supports specific resources, and the extended browser engine, such as support Business-specific tags and scripts can better support and integrate the operator's business.
  • Open Engine the standard browser engine
  • extension engine that is, the browser that supports specific resources
  • extended browser engine such as support Business-specific tags and scripts can better support and integrate the operator's business.
  • Internal Server includes:
  • the message filtering and distributing module (Request Filter) is configured to determine whether the request is to access an internal resource or an external resource, and implement a set of regular rules to prevent the malicious script from accessing the Internal Server and protecting the user information from being leaked, so as to implement the authentication module 26 and the detecting unit. 231.
  • the Web Container (Web Container) is used to parse the HTTP Request, and the corresponding business logic processing flow is implemented by the Service Logic module, and is returned in the form of an HTTP Response to implement some functions of the processing module 23;
  • Service Logic Used to execute user requests received over HTTP and return the results to the user in XML. This module implements some of the functions of the analysis module 25.
  • Binding module which is used to provide Javascript to Native Code conversion, expands the capabilities of the extension engine, and enables scripts defined in the extension engine to access terminal resources to implement some functions of the processing module 23;
  • the System API Wrapper is used to encapsulate APIs provided by different operating systems for upper layer (Binding or Web Container) calls.
  • the System API Wrapper includes:
  • OS Funciton Operating system function
  • Terminal Function for providing access support for extended functions on the terminal operating system
  • a third party function is used to provide call support for functional interfaces provided by third parties.
  • the processing flow is as follows: 1.
  • the user initiates a request for accessing a specific resource through the User Interface module, that is, the user initiates a resource access request message through the client application, and requests the message. Send to the Dispatcher module.
  • the Dispatcher module transmits the request message to the extension engine and transfers it to the Request Filter module.
  • the Request Filter module determines to forward the message to the request identifier according to the user request.
  • the Internal Server or the External Networks Request Filter module is mainly under the working interface: Record the relevant information requested by the user to facilitate analysis of the user's behavior.
  • the Filter module can deny user access.
  • the Request Filter module will forward the user request to the External Network, and go to 4; if the user accesses the local resource, the Request Filter module will forward the user request to the Web Container, and go to 5.
  • the Request Filter module waits for and receives the response message from the External Network. Go to 6.
  • the Request Filter module waits for and receives the corresponding message from the Web Container, and proceeds to 11.
  • the Request Filter module detects the returned response message based on the security policy. If the security check is turned 7 , the user will be prompted with relevant security warning information, and the subsequent process will be determined according to certain strategies, and will be transferred to 10.
  • the Request Filter module sends the content of the security check to the Dispatcher module, and the Dispatcher module forwards the message to the Open Engine or the extension engine for rendering analysis according to the corresponding identifier. If you forward the message to Open Engine, go to 8; if you forward the message to the extension engine, go to 9.
  • the Open Engine parses, renders, and layouts the returned content, and sends the final result to the User Interface for display.
  • the extension engine parses, renders, and layouts the returned content, and sends the final result to the User Interface for presentation, which involves parsing and rendering the custom label.
  • the Web Container receives the relevant request and executes the corresponding business logic, and the processing result is
  • the XML method is returned to the extension engine via HTTP (returning the processing result to the Dispatcher module via HTTP, and the Dispatcher module forwards the processing result to the extension engine) for rendering, parsing, and finally presenting to the end user through the User Interface.
  • the request is directly sent to the extension engine, and the extension engine parses the request, and accesses the relevant module in the System API Wrapper through the Native mode, and the corresponding function module in the System API Wrapper calls the operating system related function, and finally processes the user's request. , and return the result to the extension engine (return the final result to the Dispatcher module, the Dispatcher module forwards the processing result to the extension engine) and finally presents it to the user.
  • the extension engine mainly performs parsing and execution of scripts, and the Binding module implements mapping between Native code and JS script code.
  • the System API wrapper mainly implements the encapsulation of the underlying system functions.
  • Open Engine is used to implement page rendering and script execution; for pages with custom tags or scripts, the rendering engine implements page rendering, script execution. .
  • Plugln calls the System API Wrapper via Native, or directly calls the operating system's functions to finally implement the relevant functions.
  • the System API Wrapper encapsulates operating system functions so that the function calls of Native and Web Containers are independent of the specific operating system.
  • the storage medium can include: ROM, RAM, Disk or disc, etc.
  • the mobile terminal receives the resource access request message sent by the user, where the request message includes the identifier information, where the identifier information indicates that the resource requested by the user is a local resource or an external resource; the mobile terminal according to the identifier information And determining, when the user requests to access the local resource, providing the user with the requested local resource according to different operating system types; and determining, by the mobile terminal, that the user requests to access the external resource according to the identifier information, providing the user with the requested access
  • the resources of the user can enable the user to access the portal through the unified resource, and realize unified access to internal resources and external resources, and provide local resources to the user according to different operating system types. The differences between different operating systems are shielded, and the unified resource access portal is adapted to various operating systems.
  • resources include data resources and other resources, such as business logic resources.
  • resources include data resources and other resources, such as business logic resources.
  • the following takes the acquisition of data as an example to illustrate how to access resources.
  • the Dispatcher module provides a unified interface function for uniformly receiving data acquisition requests (ie, resource access requests) sent by the user, and uniformly providing the acquired data (resources) to the user.
  • data acquisition requests ie, resource access requests
  • the following embodiments of the present invention focus on how to unify The interface receives data acquisition requests initiated by users through different applications, and how to feed back the requested data to the application through a unified interface.
  • the embodiment of the invention provides a data acquisition method, an apparatus and a system thereof.
  • the system includes a client device 100, a data acquisition device 200, and a network side server 300.
  • the network side server can also be referred to as an external network server.
  • the data obtaining device 200 may be integrated in the client 100 as a function module in the client 100, and the network side server 300 may be a remote web server.
  • the communication between the client 100 and the data acquisition device 200 can be performed based on the HTTP protocol.
  • the data acquisition device 200 and the network-side server 300 can communicate with each other based on the HTTP protocol.
  • the network-side server 300 can trigger the WapPush message with the data acquisition device 200. Communicate.
  • the client 100 includes one or more application programs. When multiple applications are included, each application program provides an interface unit (hereinafter referred to as a first interface unit) for supporting each application interface standard in the data acquisition device 200.
  • a data acquisition request is transmitted, and data returned by the data acquisition device 200 through the first interface unit is received.
  • Each application in client 100 is uniquely identified by an application identifier (APPID), which is carried in the number when the application needs to obtain data.
  • APPID application identifier
  • the data acquisition device 200 provides the acquired data to the corresponding application according to the identifier.
  • the user can set an offline download policy or change an offline download policy through the client 100, and synchronize the offline download policy to the data acquisition device 200.
  • the data acquisition device 200 is configured to receive, by using the first interface unit, a data acquisition request sent by the client 100, obtain corresponding data according to the data acquisition request, and provide the acquired data to the data acquisition request by using the first interface unit. s application.
  • An offline download policy is saved in the device, so that the offline data can be uniformly acquired and stored according to the saved offline download policy.
  • the offline download policy is set by the user through the client 100, or is set by the network side server 300 according to the network status and service development needs and downloaded to the data acquisition device 200.
  • the interaction of the data acquisition device 200 with the network side is achieved by a second interface unit on the device.
  • the network side server 300 is located on the network side (e.g., a local area network or a remote network) for providing the data acquisition apparatus 200 with the data required by the client 100.
  • the network side e.g., a local area network or a remote network
  • the interface protocol supported by the first interface unit between the data acquisition device 200 and the client 100 may be the same or different from the interface protocol supported by the second interface unit between the network side server 300 and the network interface server 300.
  • the data acquisition device 200 communicates with the same interface protocol as the original interface protocol of the client 100 and the network side server 300, respectively, in order to reduce the modification of the client 100 and the network side server 300.
  • the data obtaining apparatus 200 can respectively formulate suitable interface protocols for the characteristics of the network side server 300 and the client 100, so that the coupling degree between each application in the client 100 and the network side server 300 is reduced. Therefore, the upgrade of the client 100 or the network side server 300 is facilitated.
  • the network side server 300 may not be included in the above system. Since the client is usually integrated in the user equipment, the client locally described here can also be understood as the user equipment local.
  • the flow of obtaining network-side data based on the system shown in FIG. 4 can be as shown in FIG. 5, and includes the following steps:
  • Step 201 Each application in the client 100 sends a data acquisition request to the first interface unit of the data obtaining apparatus 200, where the data acquisition request includes at least an application identifier APPID.
  • the data acquisition request may further carry data location information, where the data location information indicates whether the data to be acquired is located on the network side or the user equipment/client.
  • the data acquisition request may further carry data description information, which is used to describe attribute information of the data to be acquired, such as a data name, a type, a size, a location in a file, and the like.
  • the specific format of the data acquisition request is:
  • 66.249.67.196:80 is a data location information part, indicating that the data requested by the client 100 is located at the network side server 300 with the address of 66.249.67.196, and indicates that the data is obtained from the port number 80 of the server 300; adGet is obtained.
  • the instruction of the data indicates that the advertisement data needs to be obtained;
  • the Appid is the application identification part, which is used to identify the application that requests the acquisition of the data;
  • Step 202 After receiving the data acquisition request, the data obtaining apparatus 200 determines that the requested data is located on the network side.
  • the data acquisition request carries data location information
  • the data obtaining apparatus 200 can determine, according to the information, whether the requested data is user equipment/client local data or network side data.
  • the data acquisition URL address in the data acquisition request command is 66.249.67.196:80, indicating that the data requested to be obtained is located in the network side server of the address.
  • the correspondence between the APPID and the data location may be set in the data acquisition device 200 in advance, so that the data acquisition device 200 can obtain the request according to the data.
  • the APPID carried in and the corresponding relationship determine the location of the data to be acquired by the application corresponding to the APPID.
  • Step 203 The data acquisition device 200 searches for the corresponding data from the network side to the offline data of the user equipment/client 100. If not, the process proceeds to step 204. Otherwise, step 205 is performed.
  • Step 204 The client 100 is connected to the corresponding network side server 300, and requests the network side server to download the data requested by the client 100 through the data obtaining apparatus 200.
  • this step it can be confirmed to the user by sending the inquiry information to the client 100 whether it is When the corresponding data is not obtained from the offline data, the data is downloaded in real time, if the user passes the client
  • Step 205 The data acquiring device 200 provides the acquired data to the application corresponding to the APPID through the first interface unit.
  • step 204 when the client 100 fails to acquire the requested data due to network reasons, the network side server 300, etc., the data obtaining apparatus 200 may also set the time interval or the set number of times. The remote connection is automatically made and the data requested by the client 100 is requested to be downloaded to the network side server.
  • the data obtaining apparatus 200 when the data obtaining apparatus 200 does not find the corresponding data from the offline data locally of the user equipment/client 100, it may further determine whether the number of times the client 100 requests the data exceeds a set threshold, and when When the judgment result is yes, a task of downloading the data is added to the download task list, so that the data is downloaded to the user equipment/client local according to the download task list and the offline download policy. This way, when the application frequently accesses a certain data, it does not have to download the data from the remote server every time, which improves the response speed.
  • the offline download policy may include one or more of the following:
  • the network is free to download to reduce congestion on the network
  • the downloaded data is specified by downloading the task list, for example, specifying related service data content such as downloading the video advertisement, or specifying the network side data content frequently requested by the download client, so that the data can be obtained according to the user preference, and the download process can also be performed.
  • the data that consumes the network resources is downloaded to the user equipment/client local in advance, so that when the data requested by the application includes the specified data, the user equipment/client locally obtains, which is convenient for accelerating the response time of the data acquisition request, and It helps to reduce the impact of narrow bandwidth or network congestion and enhance the user experience.
  • the above offline download policy whether set by the client 100 or set by the network side server 300, needs to be synchronized to the data acquisition device 200.
  • the offline download policy set by the WapPush message can be synchronized, and the offline data download process can be triggered by the WapPush message. If it is set by the client 100, the set offline download policy can be synchronized to the data acquisition device 200 by sending a request. If the offline download policy needs to be changed, the change can also be made by sending a request.
  • the data acquisition device 200 can download the related content according to the offline download policy, the request of the client 100, or the request of the network side server 300.
  • offline data can be stored by means of XML.
  • corresponding extension tags can be defined according to business needs.
  • offline data 1 stored in XML format can be:
  • the corresponding tag group can be customized through XML.
  • Contenttype represents a data type (here, the data type is advertisement data), and according to this field, the application can analyze and process the corresponding information according to the prior agreement;
  • APPID 123456
  • the advertisement data used by the application with APPID 123456;
  • the mainview is "true" to indicate that the advertisement needs to be displayed on the main page of the application;
  • the URL represents the address of the network side server connected when downloading offline data;
  • the content in the body tag For a data entity, it can be the specific content of data such as text, images, Flash, or the storage path in the user device.
  • the offline data information in the above XML format can be further refined. Set more data attribute parameters to more fully describe the data to improve the matching with the application's data acquisition request and provide more accurate data for the application.
  • the offline data stored by the above XML method can also conveniently realize the sharing of offline data by the application.
  • the shared offline data stored in the XML format 2 can be:
  • Contenttype is "application/video”, indicating that the data type of the offline data is video data;
  • APPID 000000, indicating that the video data is general-purpose video data, that is, video data that can be used by each application;
  • true means that the video needs to be displayed on the main page of the application.
  • Example 1 The application 123456 sends a data acquisition request requesting to obtain data from 66.2.67.196:80, and the data is advertisement data that needs to be displayed on the application homepage, and the request command is:
  • the offline data 1 can be applied to the data.
  • the same URL address both 66.249.67.196:80
  • the same data type both advertising data
  • data application location ie The mainview attribute is the same, so the data acquisition device 200 provides the offline data 1 to the application whose APPID is 123456.
  • Example 2 The application 123456 sends a data acquisition request requesting data from 66.249.67.125:60, and the data is video data that needs to be displayed on the application home page.
  • the request command is:
  • the offline data 2 is general data.
  • the URL address is the same (both 66.249.67.125:60)
  • the data type is the same (both video data)
  • the data application location (ie mainview) attribute is the same, so the data acquisition device 200 will be offline data 2 is provided to the application with APPID 123456.
  • Example 3 The application 654321 sends a data acquisition request requesting to obtain data from 66.249.67.125:60, and the data is video data that needs to be displayed on the application home page, and the request command is:
  • the offline data 2 is general data.
  • the URL address is the same (both 66.249.67.125:60)
  • the data type is the same (both video data)
  • the data application location (ie mainview) attribute is the same, so the data acquisition device 200 will be offline data 2 is provided to the application with APPID 654321.
  • the data obtaining apparatus 200 can search for the most matching data from the offline data according to the data acquisition request of different applications, thereby satisfying the needs of the application, and one offline data can be used by multiple applications. Shared.
  • offline data When there is a large amount of offline data stored, it can be indexed and searched based on the index, so as to speed up the data search and the response speed of the request. For example, it can be based on offline data pairs
  • the information such as APPID, Contenttype, and server URL address is used to index offline data.
  • searching it can be searched based on index information.
  • the APPID corresponding to the offline data is used as the first index field and the index table is established according to a certain rule (such as APPID ascending order), which includes the physical storage location information of the APPID and the corresponding offline data, and is searched for offline matching with the application data acquisition request.
  • a certain rule such as APPID ascending order
  • the physical storage location of the offline data corresponding to the APPID in the data acquisition request can be quickly located according to the So-I table to speed up the search.
  • the attribute information of the offline data (such as the URL address) can be used as the second index field to build an index table, thereby further improving the data search speed.
  • the index table will be updated when the attribute information of the offline data is added, deleted or updated, it is necessary to consider the balance between the index table storage space, the index information maintenance, and the data search efficiency when establishing the index.
  • the process of acquiring the local data of the user equipment/client based on the system shown in FIG. 4, as shown in FIG. 6, includes the following steps:
  • Step 301 Each application in the client 100 sends a data acquisition request to the first interface unit of the data obtaining apparatus 200, where the data acquisition request includes at least an application identifier.
  • the data acquisition request may also carry data location information and data description information.
  • the specific format of the data acquisition request is:
  • 127.0.0.1:80 is the data location information part, indicating the storage path of the acquired data in the user equipment; adGet is an instruction to obtain data, indicating that the advertisement data needs to be acquired; Appid is an application identification part, which is used to identify the request acquisition. Data application.
  • Step 302 After receiving the data acquisition request, the data obtaining apparatus 200 determines that the requested data is located locally in the user equipment/client.
  • the data acquisition request carries data location information
  • the data obtaining apparatus 200 can determine, according to the information, whether the requested data is user equipment/client local data or remote data.
  • the data acquisition address in the data acquisition request command is Http://127.0.0.1:80, indicating that the data requested to be obtained is located locally on the user equipment/client.
  • Some applications need to obtain a relatively simple data content, and the storage location of the data content is relatively fixed. Therefore, the correspondence between the APPID and the data location may be set in the data acquisition device 200 in advance, so that the data acquisition device 200 can obtain the request according to the data.
  • the APPID carried in the correspondence and the correspondence determine the location of the data to be acquired by the application corresponding to the APPID.
  • Step 303 The data obtaining apparatus 200 acquires corresponding data from the local device/client 100 according to the data location information. If yes, step 304 is performed; otherwise, step 305 is performed.
  • Step 304 The data obtaining device 200 provides the acquired data to the application corresponding to the APPID through its first interface unit.
  • Step 305 Abandon the data acquisition operation, and end the data acquisition process.
  • the data acquisition device in the embodiment of the present invention may include the following functional units as shown in FIG. 7.
  • the data acquisition device includes at least a first interface unit 1 and a data acquisition unit 2.
  • the first interface unit 1 is configured to receive a data acquisition request sent by each application in the client 100, where the data acquisition request carries at least an application identifier, and may also carry data location information;
  • the data acquired by the data obtaining unit 2 is provided to an application corresponding to the application identifier; the first interface unit can implement part of the functions of the message distribution Dispatcher module shown in FIG. 3.
  • the data acquisition unit 2 is configured to acquire corresponding data according to the data acquisition request received by the first interface unit 1, and send the acquired data to the first interface unit 1.
  • the data acquisition unit can implement some of the functions of the message filtering distribution module, the web container, the extension engine, and related modules in the System API Wrapper shown in Figure 3.
  • the data acquisition device may further include a determination unit 3; further, the data acquisition unit 2 includes an offline data acquisition module 2001 and a local acquisition module 2003, wherein
  • the determining unit 3 is configured to determine, according to the data location information carried in the data acquisition request, whether the requested data is located on the network side or the client/user equipment local.
  • the function implemented by the determining unit 3 can also be implemented by two determining units.
  • the first determining unit is configured to determine, according to the data location information carried in the data acquisition request, whether the requested data is located on the network side
  • the second determining unit is configured to determine, according to the data location information carried in the data acquisition request, the requested The data obtained is Whether it is located locally on the client/user device; the determining unit 3 can implement some functions of the message filtering and distributing module shown in FIG.
  • the offline data obtaining module 2001 is configured to: when the determining unit 3 determines that the requested data is located on the network side, download the corresponding data from the network side to the offline data of the user equipment/client local; the offline data obtaining module 2001 can implement Part of the functionality of the web container shown in Figure 3.
  • the local obtaining module 2003 is configured to: when the determining unit 3 determines that the requested data is located locally on the client/user device, locally acquire data from the client/user device according to the path indicated by the data location information.
  • the local acquisition module 2003 can implement some of the functions of the web container shown in FIG.
  • the data acquisition device further includes a second interface unit 5; the data acquisition unit 2 further includes: a remote acquisition module 2002;
  • the remote obtaining module 2002 is configured to: when the offline data acquiring module 2001 does not obtain the corresponding data, send a data download request to the second interface unit 5; and further, receive the data returned by the second interface unit 5;
  • the unit 5 is configured to connect the network side server indicated by the data location information according to the request of the remote acquisition module 2002, and acquire corresponding data from the server.
  • the remote acquisition module 2002 can implement some functions of the message filtering distribution module shown in FIG. 3.
  • the second interface unit is equivalent to the interface portion between the message distribution module shown in Fig. 3 and the external network.
  • the data obtaining apparatus may further include: an offline data downloading unit 4, configured to download network side data from the remote server through the second interface unit 5 according to the download task list and the offline downloading policy, and save the downloaded data to the user equipment/ Client local offline data.
  • the offline data downloading unit 4 is further configured to: when the offline data obtaining module 2001 does not obtain the corresponding data, determine the number of times the client requests the data, and when the number reaches the set threshold, add in the download task list. The task of downloading this data.
  • the offline data download unit can implement some of the functions of the message filtering distribution module in the internal server shown in Figure 3.
  • the data acquisition request sent by each application in the client is received by the unified interface unit, and after the required data is acquired according to the data acquisition request, the application that sends the data acquisition request is provided through the unified interface unit.
  • the program correspondingly, the network side server for storing data only needs to provide a connection to the data acquisition device to provide the data requested by the client. Therefore, compared with the prior art, each application obtains data through its own interface, saves port resources, and the technology is simple to implement.
  • the offline downloading policy when the offline data is acquired, the offline downloading policy may be downloaded when the network is available, the network idle downloading, the fixed time downloading, the specific data content being downloaded in advance, and the like, and the offline data is performed according to the network usage status or the user habit. Downloading provides users with convenience and increased flexibility for offline data downloads. Further, the downloaded offline data is stored in an index manner, and can be searched based on an index manner, so as to speed up data search and request response speed.
  • the present invention cover the modifications and variations of the inventions

Description

资源访问方法及资源访问系统 技术领域
本发明涉及通信技术领域， 尤其涉及一种资源访问方法及资源访问系统。 背景技术
目前， 移动终端需要通过不同的浏览器实现对本机资源的访问。 为了扩 展对资源的应用， 在移动终端上开发任何一个功能插件（例如 media player ), 必须严格遵循不同的操作系统和浏览器的插件实现机制。 发明人在实现本发 明的过程中， 发现利用现有技术在移动终端上开展具体业务时， 需要针对不 同的操作系统及浏览器进行适配， 开发过程复杂、 开发周期长、 业务功能模 块可重用性差、 可扩展性低。 另外， 现有技术中移动终端只能对内部资源和 外部资源分别通过不同的方式进行访问， 用户的操作较复杂、 体验较差。
另外， 为了满足用户的使用需求， 用户设备的客户端中一般包括多个应 用程序 （例如浏览器、 飞信、 Email 等）， 当要启动其中一个应用程序时， 需 要获取相应资源， 例如获取广告信息以展现于客户端的界面上。 当前客户端 中的各种应用程序在获取资源时， 均通过应用程序自身的接口从网络侧服务 器中获取， 由于应用程序的多样性， 所以应用程序通过各自的接口从网络侧 服务器获取资源的方式实现复杂。 并且， 对于网络侧服务器来说， 其要为客 户端中的多个应用程序提供资源， 所以要求网络侧服务器具备与多个应用程 序进行资源交互的多个接口， 导致网络侧服务器的接口复杂、 占用端口资源 另外， 当前客户端中的很多应用程序都有对离线资源获取的业务需求。 以浏览器为例， 现有离线资源的下载主要通过用户手动提前下载的方式（例 如 "文件- >另存为" 的方式）， 其下载的资源内容单一（仅为网页内容）， 而 由于浏览器已经是最上层的和用户直接交互的程序， 所以下载的网页内容不 能被其它程序所共享。 并且浏览器只有启动后才能和互联网进行信息的交互， 交互的过程需要用户进行触发， 实现较复杂， 给用户带来了很多不便， 其它 应用程序也存在离线资源下载方式单一、 实现较复杂等问题。 发明内容
本发明实施例提供一种资源访问方法及资源访问系统， 用以实现对内部 资源和外部资源的统一访问， 以及解决现有客户端获取资源的过程实现复杂、 占用端口资源多的问题。
本发明实施例提供一种资源访问方法， 该方法包括：
通过统一接口接收用户通过客户端应用程序发送的资源访问请求消息， 所述请求消息中包含资源标识信息， 所述资源标识信息指示用户请求访问的 资源是本地资源或外部资源；
根据所述资源标识信息， 确定用户请求访问本地资源时， 将所请求访问 的本地资源通过所述统一接口提供给用户；
根据所述资源标识信息， 确定用户请求访问外部资源时， 将所请求访问 的外部资源通过所述统一接口提供给用户。
本发明实施例还提供一种资源访问系统， 包括移动终端和外部网络服务 器；
所述移动终端包括消息分发模块， 浏览器引擎和内部服务器；
消息分发模块， 用于接收用户通过客户端应用程序发送的资源访问请求 消息， 并将所述资源访问请求消息转发给内部服务器或浏览器引擎；
浏览器引擎， 用于获取资源访问请求消息中包含的资源标识信息， 并根 据所述获得的资源标识信息， 确定出用户请求访问的资源是本地资源或外部 资源， 以及将确定出的结果通知给内部服务器；
内部服务器， 用于获取资源访问请求消息中包含的资源标识信息， 并根 据所述获得的资源标识信息， 获知用户请求访问的资源是本地资源或外部资 源； 或者用于基于浏览器引擎通知给自身的结果， 获知用户请求访问的资源 是本地资源或外部资源； 还用于获取用户所请求访问的资源， 并通过所述消 息分发模块将用户所请求访问的资源提供给用户。
本发明实施例提供的资源访问方法， 通过统一接口接收用户通过客户端 应用程序发送的资源访问请求消息， 根据所述资源访问请求消息中包含的资 源标识信息确定用户请求访问本地资源时， 将所请求访问的本地资源通过所 述统一接口提供给用户； 根据所述资源访问请求消息中包含的资源标识信息 确定用户请求访问外部资源时， 将所请求访问的外部资源通过所述统一接口 提供给用户， 从而可以通过统一的资源访问入口， 实现对内部资源和外部资 源的统一访问， 以及可以通过统一接口接收各应用程序发送的资源访问请求， 并将所请求访问的资源通过该统一的接口提供给发送资源访问请求的用户， 从而节省了端口资源， 并且技术实现简单。 附图说明
图 1为本发明实施例中进行资源访问的处理流程图；
图 2A、 图 2B、 图 2C为本发明实施例中通信系统的结构示意图； 图 2D、 图 2E为本发明实施例中处理模块的结构示意图；
图 3为本发明实施例中通信系统的一个具体实例的结构示意图； 图 4为本发明实施例提供的一种数据获取系统示意图；
图 5为本发明实施例提供的一种数据获取方法流程图一；
图 6为本发明实施例提供的一种数据获取方法流程图二；
图 7为本发明实施例提供的一种数据获取装置结构图。 具体实施方式
下面结合说明书附图对本发明实施例方法进行详细说明。
如图 1所示， 本发明实施例中， 一种资源访问的处理流程如下： 步骤 11、 移动终端接收用户发送的资源访问请求消息， 该请求消息中包 含资源标识信息（为表示方便， 下面将资源标识信息简称为标识信息）， 该标 识信息指示用户请求访问的资源是本地资源或外部资源。 其中， 用户发送资 源访问请求可以有多种方式， 例如， 移动终端可以接收用户直接通过 HTTP 方式发送的资源访问请求， 也可以接收用户通过标签脚本方式发送的资源访 问请求。
步骤 12、 移动终端根据该标识信息， 确定用户请求访问本地资源或外部 资源。
步骤 13、 移动终端确定用户请求访问本地资源时， 根据不同的操作系统 类型向用户提供所请求访问的本地资源； 确定用户请求访问外部资源时， 向 用户提供所请求访问的外部资源。
若在步骤 11中， 移动终端接收到用户通过标签脚本方式发送的资源访问 请求， 则在执行步骤 12和 13之前， 需要执行标签脚本， 获得标识信息； 此 时， 步骤 12和步骤 13中， 向用户提供所请求访问的本地资源或外部资源时， 需要通过触发 HTTP请求或调用操作系统的应用程序接口， 获得用户请求访 问的本地资源或外部资源。
在步骤 13中， 移动终端向用户提供所请求访问的本地资源之前， 可以对 用户是否具有访问该本地资源的权限进行确定， 在确定用户具有访问该本地 资源的权限时， 根据不同的操作系统类型向用户提供该本地资源； 移动终端 向用户提供所请求访问的外部资源之前， 可以对用户是否具有访问该外部资 源的权限进行确定， 以及可以对该外部资源的地址是否合法进行确定， 在确 定用户具有访问该外部资源的权限， 并且该外部资源的地址合法时， 移动终 端向用户提供该外部资源。
一个实施例中， 移动终端可以从外部网络获取用户所请求的外部资源， 例如， 移动终端将用户的请求发送给外部网络后， 接收外部网络根据用户请 求返回的外部资源。 移动终端在获取到用户请求的外部资源后， 可以对该外 部资源进行安全检测， 在确定通过安全检测时， 将该外部资源提供给用户。
一个实施例中， 移动终端获取到用户请求的外部资源后， 可以根据该外 部资源中是否包含特定标签， 确定该外部资源是否为特定资源； 在确定该外 部资源是特定资源时， 将该外部资源提供给支持特定资源的浏览器进行页面 处理并展示给用户； 在确定该外部资源不是特定资源时， 将该外部资源提供 给通用浏览器进行页面处理并展示给用户。
一个实施例中， 移动终端可以根据用户请求获取本地资源， 在获取到本 地资源后， 将该本地资源提供给支持特定资源的浏览器进行页面处理并展示 给用户。 移动终端将所述本地资源提供给支持特定资源的浏览器包括： 移动 终端通过 HTTP方式将所述本地资源提供给支持特定资源的浏览器； 或， 移 动终端通知支持特定资源的浏览器调用操作系统的应用程序接口， 获得所述 本地资源。 用户后续可以对该本地资源进行操作， 如用户对移动终端厂商提 供的功能进行访问、 对移动终端操作系统自身的功能进行访问、 对第三方应 用软件进行访问其中之一或任意组合。
移动终端通过 HTTP方式将所述本地资源提供给支持特定资源的浏览器 时， 用户可进行应用程序管理、 插件管理、 本地资源搜索等操作； 移动终端 通知支持特定资源的浏览器调用操作系统的应用程序接口， 获得所述本地资 源时， 用户可使用移动终端提供的任何功能， 例如接打电话、 收发信息、 摄 像头、 音视频播放等。 其中， 用户可以通过浏览器的用户界面进行操作并提 交操作结果。 移动终端在接收到用户提交的对本地资源进行操作的操作结果 后， 可以根据操作结果更新本地资源。
一个实施例中， 移动终端可以记录向用户提供的本地资源或外部资源的 相关信息； 后续可以根据记录的相关信息， 对用户的访问行为进行分析。
本发明实施例中， 一种移动终端的结构如图 2A 所示， 包括： 接收模块 21、 确定模块 22、 处理模块 23; 其中， 接收模块 21 , 用于接收用户发送的资 源访问请求消息， 请求消息中包含标识信息， 该标识信息指示用户请求访问 的资源是本地资源或外部资源； 确定模块 22, 用于根据标识信息， 确定用户 请求访问本地资源或外部资源； 处理模块 23 , 用于在确定用户请求访问本地 资源时， 根据不同的操作系统类型向用户提供所请求访问的本地资源； 在确 定用户请求访问外部资源时， 向用户提供所请求访问的外部资源。 如图 2B所示， 一个实施例中， 图 2A所示的移动终端还可以包括： 记录 模块 24、 分析模块 25; 其中， 记录模块 24, 用于记录向用户提供的本地资源 或外部资源的相关信息； 分析模块 25 , 用于根据记录的相关信息， 对用户的 访问行为进行分析。
如图 2C所示， 一个实施例中， 图 2A所示的移动终端还可以包括： 鉴权 模块 26, 用于在向用户提供所请求访问的本地资源前， 确定用户具有访问本 地资源的权限； 以及， 在向用户提供所请求访问的外部资源前， 确定用户具 有访问外部资源的权限， 并且外部资源的地址合法。
一个实施例中， 处理模块 23向用户提供所请求访问的外部资源时， 还可 以用于从外部网络获取外部资源并提供给用户。
如图 2D所示， 一个实施例中， 处理模块 23 包括： 检测单元 231、 第一 处理单元 232; 其中， 检测单元 231 , 用于对外部资源进行安全检测； 第一处 理单元 232, 用于在确定通过安全检测时， 将外部资源提供给用户。
如图 2E所示， 一个实施例中， 处理模块 23包括： 确定单元 233、 第二处 理单元 234、 第三处理单元 235; 其中， 确定单元 233 , 用于根据该外部资源 中是否包含特定标签， 确定该外部资源是否为特定资源； 第二处理单元 234, 用于在确定外部资源是特定资源时， 将外部资源提供给支持特定资源的浏览 器进行页面处理并展示给用户； 第三处理单元 235 , 用于在确定外部资源不是 特定资源时， 将外部资源提供给通用浏览器进行页面处理并展示给用户。
一个实施例中， 接收模块 21还可以用于接收用户通过 HTTP方式或标签 脚本方式发送的所述资源访问请求。
一个实施例中， 处理模块 23向用户提供所请求访问的本地资源时， 还可 以用于获取本地资源， 将本地资源提供给支持特定资源的浏览器进行页面处 理并展示给用户。
—个实施例中， 处理模块 23将所述本地资源提供给支持特定资源的浏览 器时， 还可以用于通过 HTTP方式将所述本地资源提供给支持特定资源的浏 览器； 或， 通知支持特定资源的浏览器调用操作系统的应用程序接口， 获得 所述本地资源。
一个实施例中， 处理模块 23将本地资源提供给支持特定资源的浏览器进 行页面处理并展示给用户后， 接收模块 21还可以用于接收用户提交的对本地 资源进行操作的操作结果， 处理模块 23还可以用于根据操作结果更新本地资 源。
上述实施例中的通信设备在具体实施时， 一个实例如图 3 所示， 其中包 括浏览器 （ Browser )、 内部服务器 （ Internal Server ), 另外图 3还示出了外部 网络 ( External Network ) 及本地操作系统 ( Operating System )。 Operating System, 是本设备上的操作系统， 可以是 Windows Mobile, Symbian或其它 操作系统。 其中浏览器、 内部服务器和本地操作系统均可以集成到移动终端 中。
Browser的主要功能包括页面渲染、 脚本解析执行等。 Browser中可以包 括：
用户交互界面 （User Interface ), 即用户看到的浏览器界面， 以实现接收 模块 21的功能；
消息分发模块（Dispatcher ), 用于根据相应的配置规则及安全策略， 分发 浏览器引擎的相关请求， 例如基于资源访问请求消息的发送方式进行分发， 具体地， 在资源访问请求消息为通过 HTTP方式发送的时， 将所述资源访问 请求消息转发给内部服务器； 在资源访问请求消息为通过标签脚本方式发送 的时， 将所述资源访问请求消息转发给浏览器引擎。 以实现确定模块 22和处 理模块 23的部分功能（其中包括确定单元 233、 第二处理单元 234、 第三处 理单元 235完成的功能）；
解析渲染引擎（Render Engine ), 也即浏览器引擎， 用于实现对标签的解 析， 提供脚本的运行环境， 以实现通过浏览器和支持特定资源的浏览器的功 能；
其中， Render Engine包括标准浏览器引擎（Open Engine ), 即通用浏览 器引擎； 扩展引擎， 即支持特定资源的浏览器， 扩展浏览器引擎， 如支持运 营商特殊标签和脚本， 能够更好的支持和集成运营商的业务。
Internal Server包括：
消息过滤分发模块（Request Filter ), 用于判断请求是访问内部资源还是 外部资源， 实现一套规律规则， 防止恶意脚本访问 Internal Server, 保护用户 信息不被泄露， 以实现鉴权模块 26、 检测单元 231、 第一处理单元 232、 记录 模块 24的功能以及确定模块 22的部分功能；
Web Container ( Web容器）， 用于解析 HTTP Request, 通过 Service Logic 模块实现相应的业务逻辑处理流程， 以 HTTP Response的形式返回， 以实现 处理模块 23的部分功能；
业务逻辑模块（ Service Logic ): 用于执行以 HTTP方式接收的用户请求， 并将结果以 XML的方式返回给用户。该模块实现了分析模块 25的部分功能。
绑定模块（ Binding ), 用于提供 Javascript到 Native Code的转换， 扩展扩 展引擎的能力， 使扩展引擎中定义的脚本可以访问终端资源， 以实现处理模 块 23的部分功能；
系统程序封装模块（ System API Wrapper ), 用于将不同的操作系统提供 的 API进行封装， 供上层（ Binding或 Web Container )调用。
System API Wrapper包括：
操作系统功能（OS Funciton ), 用于提供对本机操作系统的访问支持； 终端功能（ Terminal Function ),用于提供对终端操作系统之上的扩展功能 的访问支持；
第三方扩展功能（ Third party Function ), 用于提供对第三方提供的功能接 口的调用支持。
利用图 3所示具体实例的通信设备进行资源访问时， 其处理流程如下： 1、 用户通过 User Interface模块发起访问特定资源的请求， 即用户通过客 户端应用程序发起资源访问请求消息， 并将请求发送给 Dispatcher模块。
2、 Dispatcher模块将请求消息传送给扩展引擎并转 12或传送给 Request Filter模块， Request Filter模块根据用户请求的相关标识决定将消息转给 Internal Server或者是 External Networks Request Filter模块主要工作 口下： 记录用户请求的相关信息从而便于对用户的行为进行分析。
如果用户访问的是外部资源， 验证用户是否具有合法的权限， 以及用户 访问的目的地址是否在白名单中。例如用户访问的是一个恶意网站，则 Request
Filter模块可以拒绝用户的访问。
如果用户访问的是本地资源， 验证用户是否具有发送相关请求的权限。 例如用户希望访问系统敏感数据， 则需要验证用户是否具有权限来发送该请 求。
3、 如果用户访问的是外部资源， 则 Request Filter模块会将用户请求转给 External Network, 转 4; 如果用户访问的是本地资源， 则 Request Filter模块 会将用户请求转给 Web Container， 转 5。
4、 Request Filter模块等待并接收 External Network的响应消息 , 转 6。
5、 Request Filter模块等待并接收 Web Container的相应消息， 转 11。
6、 Request Filter模块对返回的响应消息基于安全策略进行检测。 如果通 过安全检测转 7 , 否则提示用户相关安全警告信息， 并根据一定策略决定后续 流程， 并转 10。
7、 Request Filter模块将经过安全检测的内容发送给 Dispatcher模块， Dispatcher模块根据相应标识将消息转发给 Open Engine或者是扩展引擎进行 渲染解析。 如果将消息转发给 Open Engine, 转 8; 如果将消息转发给扩展引 擎， 转 9。
8、 Open Engine对返回的内容进行解析、 渲染和版面布局， 并将最终结 果发送给 User Interface进行展示。
9、 扩展引擎对返回的内容进行解析、 渲染和版面布局， 并将最终结果发 送给 User Interface进行展示， 其中涉及到对自定义的标签进行解析和渲染。
10、 如果用户选择继续浏览， 则转 7; 如果用户选择放弃浏览， 则结束后 续流程。
11、 Web Container接收相关请求， 并执行相应业务逻辑， 将处理结果以 XML的方式通过 HTTP方式返回给扩展引擎 (通过 HTTP方式将处理结果返 回给 Dispatcher模块， 由 Dispatcher模块将处理结果转发给扩展引擎 )进行渲 染、 解析并最终通过 User Interface展现给最终用户。
12、请求直接发送给扩展引擎，由扩展引擎对请求进行解析，并通过 Native 方式访问 System API Wrapper中的相关模块，由 System API Wrapper中的相应 功能模块调用操作系统相关功能， 最终处理用户的请求， 并将结果返回给扩 展引擎 (将最终结果返回给 Dispatcher模块， 由 Dispatcher模块将处理结果转 发给扩展引擎）并最终展现给用户。 扩展引擎主要完成对脚本的解析和执行， 而 Binding模块实现了 Native代码和 JS脚本代码之间的映射。 System API wrapper主要实现了对底层系统函数的封装。
上述处理流程中， 对于仅包含开放的 HTML标签以及 JavaScript脚本的 页面， 由 Open Engine来实现页面渲染， 脚本执行； 对于含有自定义的标签或 脚本的页面， 由扩展引擎来实现页面渲染， 脚本执行。
如果网页的正常显示和用户的操作需要 Plugln 的配合才能完成， 则 Render Engine会调用相关的 Plugln以便实现对扩展功能的调用。 Plugln会通 过 Native方式调用 System API Wrapper,或者直接调用操作系统的函数最终实 现相关功能。
System API Wrapper主要对操作系统函数进行了封装， 从而使得 Native 和 Web Container的函数调用独立于具体的操作系统。
本领域普通技术人员可以理解上述实施例方法中的全部或部分步骤是可 以通过程序来指令相关的硬件完成， 该程序可以存储于一计算机可读存储介 质中， 存储介质可以包括： ROM、 RAM, 磁盘或光盘等。
本发明实施例中， 移动终端接收用户发送的资源访问请求消息， 所述请 求消息中包含标识信息， 所述标识信息指示用户请求访问的资源是本地资源 或外部资源； 移动终端根据所述标识信息， 确定用户请求访问本地资源时， 根据不同的操作系统类型向用户提供所请求访问的本地资源； 移动终端根据 所述标识信息， 确定用户请求访问外部资源时， 向用户提供所请求访问的外 部资源， 从而可以使用户在通过移动终端进行资源访问时， 可以通过统一的 资源访问入口， 实现对内部资源和外部资源的统一访问， 并且， 根据不同的 操作系统类型向用户提供本地资源， 可以屏蔽不同操作系统的差异， 将所述 统一的资源访问入口适配于各种操作系统。
基于本领域技术人员的公知常识， 资源包括数据资源及其他的资源， 例 如业务逻辑资源等。 下面以对数据的获取为例来说明如何进行资源的访问。
在本发明上述的具体实施方式中， 公开了如何在数据获取过程中， 实现 对内部数据和外部数据的统一获取。 结合图 3 所示， 在本发明上述的具体实 施方式中还公开了在获取到所请求的数据后，统一通过 Dispatcher模块将获取 到的数据转发给浏览器引擎进行数据的展现。其中 Dispatcher模块起到了统一 接收用户发送的数据获取请求 （即资源访问请求） 消息， 和统一将获取到的 数据（资源）提供给用户的统一接口功能， 本发明下面的实施例着重描述如 何通过统一的接口接收用户通过不同应用程序发起的数据获取请求， 以及如 何通过统一的接口将所请求的数据反馈给应用程序的过程。
本发明实施例提出一种数据获取方法及其装置和系统， 如图 4所示， 该 系统包括用户设备的客户端 100、 数据获取装置 200以及网络侧服务器 300。 网络侧服务器也可以称为外部网络服务器。 其中， 数据获取装置 200可以集 成于客户端 100中作为客户端 100中的功能模块， 网络侧服务器 300可以为 远程 Web服务器。 客户端 100和数据获取装置 200之间可以基于 HTTP协议 进行通信； 数据获取装置 200和网络侧服务器 300之间可以基于 HTTP协议 进行通信， 网络侧服务器 300可以通过 WapPush消息触发方式与数据获取装 置 200进行通信。
其中， 客户端 100中包括一个或多个应用程序， 当包括多个应用程序时， 各个应用程序向数据获取装置 200 中用于支持各应用程序接口标准的接口单 元（以下称第一接口单元）发送数据获取请求， 并接收数据获取装置 200通 过该第一接口单元返回的数据。 客户端 100 中的每个应用程序以应用程序标 识（APPID )进行唯一标识， 当应用程序需要获取数据时， 将此标识携带在数 据获取请求中， 以便于数据获取装置 200根据该标识将获取到的数据提供给 对应的应用程序。 进一步地， 用户可以通过客户端 100设置离线下载策略或 更改离线下载策略， 并将离线下载策略同步到数据获取装置 200中。
数据获取装置 200,用于通过第一接口单元接收客户端 100发送的数据获 取请求， 根据该数据获取请求获取相应的数据， 并将获取到的数据通过该第 一接口单元提供给发出数据获取请求的应用程序。 该装置中保存有离线下载 策略， 使其可根据保存的离线下载策略实现离线数据的统一获取和存储。 离 线下载策略由用户通过客户端 100设置， 或由网络侧服务器 300根据网络状 态以及业务开展需要进行设置并下载到数据获取装置 200 中。 数据获取装置 200与网络侧的交互通过该装置上的第二接口单元实现。
网络侧服务器 300位于网络侧（如局域网络或远程网络）， 用于为数据获 取装置 200提供客户端 100所需要的数据。
数据获取装置 200与客户端 100之间的第一接口单元支持的接口协议， 以 及其与网络侧服务器 300之间的第二接口单元支持的接口协议可以相同或者 不同。 对于已经商用的应用程序， 数据获取装置 200分别釆用与客户端 100和 网络侧服务器 300原有的接口协议相同的接口协议进行通信， 以便减少对客户 端 100以及网络侧服务器 300的改造。 对于尚未商用的应用程序， 数据获取装 置 200可针对网络侧服务器 300和客户端 100的特点分别制定适合的接口协议， 使得客户端 100中各应用程序与网络侧服务器 300之间的耦合度降低， 从而利 于客户端 100或者网络侧服务器 300的升级改造。
当客户端 100中的应用程序只需从用户设备 /客户端本地获取数据时，上述 系统中可以不包括网络侧服务器 300。 由于客户端通常集成于用户设备， 此处 所述的客户端本地也可理解为用户设备本地。
基于图 4所示的系统实现网络侧数据的获取的流程， 可如图 5所示， 包 括如下步骤：
步骤 201、 客户端 100中各应用程序向数据获取装置 200的第一接口单元发 送数据获取请求， 该数据获取请求中至少包括应用程序标识 APPID。 该步骤中， 数据获取请求中还可携带数据位置信息， 该数据位置信息指 示出需要获取的数据位于网络侧还是用户设备 /客户端。 数据获取请求中还可 进一步携带数据描述信息， 用于描述需要获取的数据的属性信息， 如数据名 称、 类型、 大小、 在某个文件中的位置等。 例如， 数据获取请求的具体格式 为：
Http :〃66.249.67.196: 80/adGet? Appid= 123456&mainview=tme
其中， 66.249.67.196:80为数据位置信息部分， 表示客户端 100请求获取的 数据位于地址为 66.249.67.196的网络侧服务器 300 , 并指示出从该服务器 300 的端口号 80获取数据； adGet为获取数据的指令,表示需要获取广告数据； Appid 为应用程序标识部分， 用于标识表示请求获取数据的应用程序； Mainview= "ture" 为数据描述信息， 表示所要获取的数据将在应用程序的主界面上进行 显示。
步骤 202、 数据获取装置 200接收到数据获取请求后， 判断出所请求获取 的数据位于网络侧。
通常情况下， 数据获取请求中会携带数据位置信息， 数据获取装置 200可 根据该信息判断所请求的数据是用户设备 /客户端本地数据还是网络侧数据。 例如， 上述数据获取请求命令中的数据获取 URL地址为 66.249.67.196:80 , 表 示请求获取的数据位于该地址的网络侧服务器中。
有些应用程序需要获取的数据内容比较单一， 该数据内容的存储位置也 相对固定， 所以也可以预先在数据获取装置 200中设置 APPID与数据位置的对 应关系， 使数据获取装置 200可根据数据获取请求中携带的 APPID以及该对应 关系， 确定 APPID对应的应用程序所要获取的数据的位置。
步骤 203、数据获取装置 200从网络侧下载到用户设备 /客户端 100本地的离 线数据中查找对应的数据，如果未获取到，则执行步骤 204,否则执行步骤 205。
步骤 204、 客户端 100连接到相应的网络侧服务器 300, 通过数据获取装置 200向该网络侧服务器请求下载客户端 100所请求获取的数据。
该步骤中， 可以通过向客户端 100发送询问信息的方式向用户确认是否在 从离线数据中获取不到相应的数据时， 实时下载该数据， 若用户通过客户端
100确认实时下载， 则连接到相应的网络侧服务器 300 , 以进行数据下载； 若 用户通过客户端 100确认放弃下载， 则结束本次数据获取流程。
步骤 205、 数据获取装置 200将获取到的数据， 通过第一接口单元提供给 APPID对应的应用程序。
上述流程中， 当步骤 204中， 由于网络原因、 网络侧服务器 300等原因， 客户端 100未能获取到所请求的数据时， 数据获取装置 200还可根据设定的 时间间隔或设定的次数自动进行远程连接并向该网络侧服务器请求下载客户 端 100所请求获取的数据。
上述流程中， 当数据获取装置 200从用户设备 /客户端 100本地的离线数 据中未查找到对应的数据时， 还可进一步判断客户端 100请求该数据的次数 是否超过设定阔值， 并当判断结果为是时， 在下载任务列表中添加下载该数 据的任务， 以便根据该下载任务列表以及离线下载策略将该数据下载到用户 设备 /客户端本地。 这样， 当应用程序对某个数据频繁访问时， 可不必每次都 从远程服务器下载该数据， 从而提高了响应速度。
本实施例中， 离线下载策略可以包括如下中的一个或多个：
1、 网络可用时下载， 以减少网络不可用带来的无法和网络侧服务器进行 交互的情况；
2、 网络闲时下载， 以减少对网络的拥塞；
3、 固定时间下载， 可以根据用户使用网络的习惯进行下载， 为用户提供 方便。
本实施例中通过下载任务列表指定下载的数据， 例如指定下载视频广告 等相关业务数据内容， 或指定下载客户端频繁请求的网络侧数据内容， 从而 可根据用户喜好获取数据， 还可将下载过程比较消耗网络资源的数据提前下 载到用户设备 /客户端本地，从而当应用程序请求的数据中包含该指定数据时， 从用户设备 /客户端本地进行获取， 利于加快数据获取请求的响应时间， 以及 有利于减少窄带宽或网络拥塞等带来的影响， 增强用户体验。 上述离线下载策略， 不管是由客户端 100设置还是由网络侧服务器 300 设置， 都需要同步到数据获取装置 200中。 如果是由网络侧服务器 300设置， 可以通过 WapPush消息同步其设置的离线下载策略， 同时可以通过 WapPush 消息触发离线数据下载流程。 如果是由客户端 100设置， 则可以通过发送请 求的方式将设置的离线下载策略同步到数据获取装置 200,如果需要更改离线 下载策略， 也可以通过发送请求的方式进行更改。 数据获取装置 200可以根 据上述离线下载策略、 客户端 100的请求或网络侧服务器 300的要求， 进行 相关内容的下载。
为了方便对离线数据内容进行扩展， 离线数据可以通过 XML的方式进行 存储， 具体应用中， 可根据业务需要定义相应的扩展标签。 为了方便理解， 以 XML格式存储的离线数据 1可以为：
<?xml version: "1.0" encoding=" gb2312" ?>
<contenttype>application/ advertisement</contenttype>
<APPID>123456</APPID>
<URL>Http:// 66.249.67.196: 80/adGet</URL>
<mainview>true</ mainview>
<body>
</body>
以上仅为示例格式， 针对不同的应用程序， 可以通过 XML定制相应的标 签组。 在上述离线数据的存储示例中， Contenttype代表数据类型（此处代表数 据类型为广告数据） ， 应用程序根据此字段可以按照预先的约定分析处理相 应信息； APPID=" 123456", 代表该广告数据是供 APPID为 123456的应用程序 使用的广告数据； mainview为 "true" 代表该广告需要在应用程序的主页面上 进行显示； URL代表下载离线数据时连接的网络侧服务器的地址； body标签 中的内容为数据实体， 可以是文字、 图片、 Flash等数据的具体内容或在用户 设备中的存储路径。 当然可以进一步细化上述 XML格式下的离线数据信息， 设置更多的数据属性参数， 从而更全面地对数据进行描述， 以提高与应用程 序的数据获取请求的匹配程度， 为应用程序提供更加准确的数据。
通过上述 XML方式存储的离线数据还可以方便地实现应用程序对离线数 据的共享， 例如， 以 XML格式存储的共享离线数据 2可以为：
<?xml version: "1.0" encoding=" gb2312" ?>
<contenttype>application/video</contenttype>
<APPID>000000</APPID>
<URL>Http:// 66.249.67.125:60/viGet</URL>
<mainview>true</ mainview>
<body>
</body>
上述示例中, Contenttype为 "application/video"表示该离线数据的数据类 型为视频数据； APPID="000000", 表示该视频数据为通用的视频数据， 即各 个应用程序都可以使用的视频数据； mainview为 "true" 表示该视频需要在应 用程序的主页面上进行显示。
以上述用户设备上存储的离线数据 1和离线数据 2为例， 通过以下 3个实例 来描述不同的应用程序获取所需的离线数据以及离线数据被不同应用程序所 共享的过程。
实例 1、 应用程序 123456发送数据获取请求， 请求获取来自 66.2.67.196:80 的数据， 并且该数据为需要显示在应用程序主页上的广告数据， 该请求命令 为：
Http :〃66.249.67.196: 80/adGet? Appid= 123456&mainview=tme
数据获取装置 200根据该数据获取请求从用户设备中的离线数据中查找 相应的数据时， 由于离线数据 1的属性与该数据获取请求所要求获取的数据相 匹配， 包括离线数据 1可应用于该应用程序， 另外， URL地址相同 （都是 66.249.67.196:80 ) 、 数据类型相同 （都是广告数据） 、 数据应用位置 （即 mainview ) 属性相同， 因此数据获取装置 200将离线数据 1提供给 APPID为 123456的应用程序。
实例 2、 应用程序 123456发送数据获取请求， 请求获取来自 66.249.67.125:60的数据， 并且该数据为需要显示在应用程序主页上的视频数 据， 该请求命令为：
Htt :// 66.249.67.125: 60/viGet?Appid=l 23456&mainview=tme
数据获取装置 200根据该数据获取请求从用户设备中的离线数据中查找 相应的数据时， 由于离线数据 2的属性与该数据获取请求所要求获取的数据相 匹配， 包括离线数据 2是通用数据， 可应用于该应用程序， 另外， URL地址相 同 （都是 66.249.67.125:60 ) 、 数据类型相同 （都是视频数据） 、 数据应用位 置（即 mainview )属性相同， 因此数据获取装置 200将离线数据 2提供给 APPID 为 123456的应用程序。
实例 3、 应用程序 654321发送数据获取请求， 请求获取来自 66.249.67.125:60的数据， 并且该数据为需要显示在应用程序主页上的视频数 据， 该请求命令为：
Http:〃 66.249.67.125:60/viGet?Appid=654321&mainview=tme
数据获取装置 200根据该数据获取请求从用户设备中的离线数据中查找 相应的数据时， 由于离线数据 2的属性与该数据获取请求所要求获取的数据相 匹配， 包括离线数据 2是通用数据， 可应用于该应用程序， 另外， URL地址相 同 （都是 66.249.67.125:60 ) 、 数据类型相同 （都是视频数据） 、 数据应用位 置（即 mainview )属性相同， 因此数据获取装置 200将离线数据 2提供给 APPID 为 654321的应用程序。
从以上 3个实例可以看出， 数据获取装置 200可根据不同的应用程序的数 据获取请求从离线数据中查找最为匹配的数据， 从而满足应用程序的需要， 并且一个离线数据可以被多个应用程序所共享。
当存储的离线数据比较多时， 可以通过建立索引并基于索引进行查找的 方式， 以便于加快数据查找和请求的响应速度。 例如， 可以根据离线数据对 应的 APPID、 Contenttype, 服务器 URL地址等信息为离线数据建立索引， 查找 时可以基于索引信息进行查找。 例如：
将离线数据对应的 APPID作为第一索引字段并按照一定规则 （如 APPID 升序）建立索引表， 其中包含 APPID与相应的离线数据的物理存储位置信息， 当查找与应用程序的数据获取请求匹配的离线数据时， 可以根据索 I表快速 定位到数据获取请求中的 APPID所对应的离线数据的物理存储位置，以加快查 找速度。 还可以在此基础上， 将离线数据的属性信息 （如 URL地址）作为第 二索引字段建立索引表， 进一步提高数据查找速度。
由于当增加、 删除或者更新离线数据的属性信息时， 索引表将相应更新， 因此， 在建立索引时需要考虑索引表存储空间、 索引信息维护， 以及数据查 找效率之间的平衡。
基于图 4所示的系统实现用户设备 /客户端本地数据的获取流程， 可如图 6 所示， 包括如下步骤：
步骤 301、 客户端 100中各应用程序向数据获取装置 200的第一接口单元发 送数据获取请求， 该数据获取请求中至少包括应用程序标识。
同图 2流程中的步骤 201 , 数据获取请求中还可携带数据位置信息， 以及 数据描述信息。 例如， 数据获取请求的具体格式为：
Http://127.0.0.1:80/adGet?Appid=123456
其中， 127.0.0.1:80为数据位置信息部分， 表示获取的数据在用户设备中 的存储路径； adGet为获取数据的指令， 表示需要获取广告数据； Appid为应用 程序标识部分， 用于标识请求获取数据的应用程序。
步骤 302、 数据获取装置 200接收到数据获取请求后， 判断出所请求获取 的数据位于用户设备 /客户端本地。
通常情况下， 数据获取请求中会携带数据位置信息， 数据获取装置 200可 根据该信息判断所请求的数据是用户设备 /客户端本地数据还是远程数据。 例 如， 上述数据获取请求命令中的数据获取地址为 Http://127.0.0.1 :80, 表示请求 获取的数据位于用户设备 /客户端本地。 有些应用程序需要获取的数据内容比较单一， 该数据内容的存储位置也 相对固定， 所以也可以预先在数据获取装置 200中设置 APPID与数据位置的对 应关系， 使数据获取装置 200可根据数据获取请求中携带的 APPID以及该对应 关系确定 APPID对应的应用程序所要获取的数据的位置。
步骤 303、 数据获取装置 200根据该数据位置信息从用户设备 /客户端 100 的本地获取相应的数据， 如果获取到， 则执行步骤 304; 否则执行步骤 305。
步骤 304、 数据获取设备 200将获取到的数据通过其第一接口单元提供给 APPID所对应的应用程序。
步骤 305、 放弃数据获取操作， 并结束本次数据获取流程。
本发明实施例中的数据获取装置可如图 7所示， 包括如下功能单元： 该数据获取装置至少包括第一接口单元 1和数据获取单元 2。 其中， 第一接口单元 1 ,用于接收客户端 100中各应用程序发送的数据获取请求， 该数据获取请求中至少携带应用程序标识， 还可携带数据位置信息； 第一接 口单元 1还用于将数据获取单元 2获取到的数据提供给与应用程序标识对应 的应用程序；第一接口单元能实现图 3所示的消息分发 Dispatcher模块的部分 功能。
数据获取单元 2,用于根据第一接口单元 1接收的数据获取请求获取相应 的数据， 并将获取到的数据发送到第一接口单元 1。 数据获取单元能实现图 3 所示的消息过滤分发模块、 Web容器、 扩展引擎， 以及 System API Wrapper 中的相关模块的部分功能。
该数据获取装置还可包括判断单元 3; 进一步地，数据获取单元 2包括离 线数据获取模块 2001和本地获取模块 2003， 其中，
判断单元 3 ,用于根据数据获取请求中携带的数据位置信息判断所请求获 取的数据位于网络侧还是客户端 /用户设备本地。 该判断单元 3所实现的功能 也可以通过两个判断单元实现。 如， 第一判断单元， 用于根据数据获取请求 中携带的数据位置信息判断所请求获取的数据是否位于网络侧； 第二判断单 元， 用于根据数据获取请求中携带的数据位置信息判断所请求获取的数据是 否位于客户端 /用户设备本地； 判断单元 3能实现图 3所示的消息过滤分发模 块的部分功能。
离线数据获取模块 2001 , 用于当判断单元 3判断所请求获取的数据位于 网络侧时， 从网络侧下载到用户设备 /客户端本地的离线数据中获取相应的数 据； 离线数据获取模块 2001能实现图 3所示的 Web容器的部分功能。
本地获取模块 2003， 用于当判断单元 3判断所请求获取的数据位于客户 端 /用户设备本地时， 根据数据位置信息所指示的路径从客户端 /用户设备本地 获取数据。 本地获取模块 2003能实现图 3所示的 Web容器的部分功能。
进一步地， 上述数据获取装置还包括第二接口单元 5 ; 数据获取单元 2还 包括： 远程获取模块 2002;
其中， 远程获取模块 2002 , 用于当离线数据获取模块 2001未获取到相应 的数据时， 向第二接口单元 5发送数据下载请求； 还用于接收第二接口单元 5 返回的数据； 第二接口单元 5 , 用于根据远程获取模块 2002的请求连接数据 位置信息所指示的网络侧服务器， 并从该服务器获取相应的数据。 其中， 远 程获取模块 2002能实现图 3所示的消息过滤分发模块的部分功能。 第二接口 单元相当于图 3所示的消息分发模块与外部网络之间的接口部分。
上述数据获取装置还可以包括： 离线数据下载单元 4 , 用于根据下载任务 列表以及离线下载策略， 通过第二接口单元 5从远程服务器中下载网络侧数 据， 并将下载的数据保存到用户设备 /客户端本地的离线数据中。 该离线数据 下载单元 4进一步用于， 当离线数据获取模块 2001未获取到相应的数据时， 确定客户端对该数据的请求次数， 当该次数到达设定阔值时， 在下载任务列 表中添加下载该数据的任务。 离线数据下载单元能实现图 3 所示的内部服务 器中消息过滤分发模块的部分功能。
通过上述技术方案， 通过统一接口单元接收客户端中各应用程序发送的 数据获取请求， 并在根据该数据获取请求获取到需要的数据后， 通过该统一 的接口单元提供给发送数据获取请求的应用程序， 相应地， 用于存储数据的 网络侧服务器也只需提供一个向数据获取装置提供客户端所请求的数据的接 口， 从而与现有技术中各应用程序通过各自的接口获取数据相比， 节省了端 口资源， 并且技术实现简单。
另外， 上述实施例在进行离线数据的获取时， 可根据离线下载策略在网 络可用时下载、 网络闲时下载、 固定时间下载、 特定数据内容提前下载等， 根据网络使用状况或用户习惯进行离线数据下载， 为用户提供了方便并且增 加了离线数据下载的灵活性。 进一步地， 对下载的离线数据按照索引方式进 行存储， 并可基于索引方式进行查找， 以便于加快数据查找和请求响应速度。 发明的精神和范围。 这样， 倘若本发明的这些修改和变型属于本发明权利要 求及其等同技术的范围之内， 则本发明也意图包含这些改动和变型在内。

Claims

权 利 要 求
1、 一种资源访问方法， 其特征在于， 该方法包括：
通过统一接口接收用户通过客户端应用程序发送的资源访问请求消息， 所述请求消息中包含资源标识信息， 所述资源标识信息指示用户请求访问的 资源是本地资源或外部资源；
根据所述资源标识信息， 确定用户请求访问本地资源时， 将所请求访问 的本地资源通过所述统一接口提供给用户；
根据所述资源标识信息， 确定用户请求访问外部资源时， 将所请求访问 的外部资源通过所述统一接口提供给用户。
2、 如权利要求 1所述的方法， 其特征在于， 所述接收用户发送的资源访 问请求消息包括： 接收用户直接通过 HTTP方式发送的资源访问请求消息。
3、 如权利要求 1所述的方法， 其特征在于， 所述接收用户发送的资源访 问请求消息包括： 接收用户通过标签脚本方式发送的资源访问请求消息。
4、 如权利要求 3所述的方法， 其特征在于， 在接收到用户通过标签脚本 方式发送的资源访问请求之后， 进一步执行标签脚本， 获得所述资源标识信 息。
5、 如权利要求 1所述的方法， 其特征在于， 确定用户请求访问本地资源 时， 从客户端本地保存的资源中获取所请求访问的本地资源。
6、 如权利要求 1所述的方法， 其特征在于， 确定用户请求访问外部资源 时， 从网络侧下载到客户端本地的离线资源中获取所请求访问的外部资源。
7、 如权利要求 1所述的方法， 其特征在于， 确定用户请求访问外部资源 时， 从网络侧下载到客户端本地的离线资源中查询所请求访问的外部资源， 并当未查询到时， 连接到网络侧服务器， 从该服务器获取所请求访问的外部 资源。
8、 如权利要求 6或 7所述的方法， 其特征在于， 所述下载到客户端本地 的离线资源通过该离线资源可被调用的应用程序信息以及该离线资源的属性 信息进行描述；
所述从网络侧下载到客户端本地的离线资源中获取或查询所请求访问的 外部资源， 具体为：
根据从网络侧下载到客户端本地的离线资源所对应的可被调用的应用程 序信息以及属性信息， 获取或查询分别与资源访问请求消息中所包含的应用 程序标识和数据属性信息相匹配的资源。
9、 如权利要求 8所述的方法， 其特征在于， 所述可被调用的应用程序信 息为应用程序标识， 或者为表示可被所有应用程序调用的通用标识。
10、 如权利要求 7 所述的数据获取方法， 其特征在于， 当从网络侧下载 到客户端本地的离线资源中未查询到所请求获取的外部资源时， 还包括步骤： 确定所述客户端对该资源的请求次数， 当该请求次数到达设定阔值时， 在下载任务列表中添加下载该资源的任务。
11、 如权利要求 1 所述的方法， 其特征在于， 用户通过客户端应用程序 发送的资源访问请求消息中还包含该应用程序的标识；
所述通过统一接口提供给用户， 具体为：
通过统一接口提供给与所述应用程序的标识对应的应用程序。
12、 如权利要求 11所述的方法， 其特征在于， 所述将所请求访问的本地 资源通过统一接口提供给用户， 具体包括：
将所请求访问的本地资源通过统一接口提供给支持特定资源的浏览器进 行页面处理， 并通过所述应用程序的界面展示给用户。
13、 如权利要求 12所述的方法， 其特征在于， 将所请求访问的本地资源 展示给用户后， 进一步包括：
接收用户提交的对所述本地资源进行操作的操作结果， 根据所述操作结 果更新本地资源。
14、 如权利要求 13所述的方法， 其特征在于， 所述操作包括： 对移动终 端厂商提供的功能进行访问、 对移动终端操作系统自身的功能进行访问、 对 第三方应用软件进行访问其中之一或任意组合。
15、 如权利要求 1 所述的方法， 其特征在于， 在将所请求访问的本地资 源提供给用户之前进一步包括： 确定该用户具有访问所述本地资源的权限； 在将所请求访问的外部资源提供给用户之前进一步包括： 确定该用户具 有访问所述外部资源的权限， 并且所述外部资源的地址合法。
16、 如权利要求 11所述的方法， 其特征在于， 所述将所请求访问的外部 资源通过统一接口提供给用户包括：
根据所请求访问的外部资源中是否包含特定标签， 确定所述外部资源是 否为特定资源；
确定所述外部资源是特定资源时， 将所述外部资源通过统一接口提供给 支持特定资源的浏览器进行页面处理， 并通过所述应用程序的界面展示给用 户；
确定所述外部资源不是特定资源时， 将所述外部资源通过统一接口提供 给通用浏览器进行页面处理， 并通过所述应用程序的界面展示给用户。
17、 如权利要求 1所述的方法， 其特征在于， 进一步包括：
记录向用户提供的本地资源或外部资源的相关信息；
根据记录的所述相关信息， 对用户的访问行为进行分析。
18、 一种资源访问系统， 包括移动终端和外部网络服务器， 其特征在于， 所述移动终端包括消息分发模块， 浏览器引擎和内部服务器；
消息分发模块， 用于接收用户通过客户端应用程序发送的资源访问请求 消息， 并将所述资源访问请求消息转发给内部服务器或浏览器引擎；
浏览器引擎， 用于获取资源访问请求消息中包含的资源标识信息， 并根 据所述获得的资源标识信息， 确定出用户请求访问的资源是本地资源或外部 资源， 以及将确定出的结果通知给内部服务器；
内部服务器， 用于获取资源访问请求消息中包含的资源标识信息， 并根 据所述获得的资源标识信息， 获知用户请求访问的资源是本地资源或外部资 源； 或者用于基于浏览器引擎通知给自身的结果， 获知用户请求访问的资源 是本地资源或外部资源； 还用于获取用户所请求访问的资源， 并通过所述消 息分发模块将用户所请求访问的资源提供给用户。
19、 如权利要求 18所述的系统， 其特征在于，
所述消息分发模块在接收到的资源访问请求消息为通过 HTTP方式发送 的时， 将所述资源访问请求消息转发给内部服务器；
所述消息分发模块在接收到的资源访问请求消息为通过标签脚本方式发 送的时， 将所述资源访问请求消息转发给浏览器引擎。
20、 如权利要求 19所述的系统， 其特征在于， 所述浏览器引擎在接收到 用户通过标签脚本方式发送的资源访问请求之后， 执行标签脚本， 获得所述 资源访问请求消息中包含的资源标识信息。
21、 如权利要求 18所述的系统， 其特征在于， 所述内部服务器在获知用 户请求访问本地资源时， 从客户端本地保存的资源中获取所请求访问的本地 资源。
22、 如权利要求 18所述的系统， 其特征在于， 所述内部服务器在获知用 户请求访问外部资源时， 从外部网络服务器下载到客户端本地的离线资源中 获取所请求访问的外部资源。
23、 如权利要求 18所述的系统， 其特征在于， 所述内部服务器在获知用 户请求访问外部资源时， 从外部网络服务器下载到客户端本地的离线资源中 查询所请求访问的外部资源， 并当未查询到时， 连接到所述外部网络服务器， 从该服务器获取所请求访问的外部资源。
24、 如权利要求 23所述的系统， 其特征在于， 所述内部服务器在从外部 网络服务器下载到客户端本地的离线资源中未查询到所请求获取的外部资源 时， 确定所述客户端对该资源的请求次数， 当该请求次数到达设定阔值时， 在下载任务列表中添加下载该资源的任务。
25、 如权利要求 18所述的系统， 其特征在于， 所述浏览器引擎包括通用 浏览器引擎和扩展浏览器引擎；
所述内部服务器当获知用户请求访问本地资源时， 将所请求访问的本地 资源发送给消息分发模块； 消息分发模块将所请求的本地资源转发给扩展浏览器引擎； 扩展浏览器引擎对所请求访问的本地资源进行页面处理， 并通过所述应 用程序的界面展示给用户。
26、 如权利要求 18所述的系统， 其特征在于， 所述内部服务器还用于获 取资源访问请求消息中包含的应用程序标识信息， 并通过所述消息分发模块 将用户所请求访问的资源提供给与所述应用程序的标识对应的应用程序。
27、 如权利要求 18所述的系统， 其特征在于，
内部服务器在将用户所请求访问的本地资源提供给用户之前， 确定该用 户具有访问该本地资源的权限；
内部服务器在将用户所请求访问的外部资源提供给用户之前， 确定该用 户具有访问该外部资源的权限， 并且确定所述外部资源的地址合法。
28、 如权利要求 18所述的系统， 其特征在于， 所述浏览器引擎包括通用 浏览器引擎和扩展浏览器引擎；
所述内部服务器根据所请求访问的外部资源中是否包含特定标签， 确定 所述外部资源是否为特定资源； 以及确定是特定资源时， 将该外部资源通过 所述消息分发模块提供给扩展浏览器引擎进行页面处理， 并通过所述应用程 序的界面展示给用户； 确定所述外部资源不是特定资源时， 将该外部资源通 过所述消息分发模块提供给通用浏览器引擎进行页面处理， 并通过所述应用 程序的界面展示给用户。
29、 如权利要求 18所述的系统， 其特征在于， 所述内部服务器还用于记 录向用户提供的本地资源或外部资源的相关信息， 才艮据记录的所述相关信息， 对用户的访问行为进行分析。
PCT/CN2008/001824 2007-11-09 2008-10-30 Procédé d'accès à des ressources et système d'accès à des ressources WO2009062396A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN200710177125.1 2007-11-09
CN2007101771251A CN101431713B (zh) 2007-11-09 2007-11-09 一种资源访问方法及设备
CN200810115488A CN101616132B (zh) 2008-06-24 2008-06-24 一种数据获取方法及其装置和系统
CN200810115488.7 2008-06-24

Publications (1)

Publication Number Publication Date
WO2009062396A1 true WO2009062396A1 (fr) 2009-05-22

Family

ID=40638326

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/001824 WO2009062396A1 (fr) 2007-11-09 2008-10-30 Procédé d'accès à des ressources et système d'accès à des ressources

Country Status (1)

Country Link
WO (1) WO2009062396A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105897703A (zh) * 2016-03-31 2016-08-24 阔地教育科技有限公司 信息互动方法、信息互动终端、信息互动系统及管理平台
CN112749393A (zh) * 2019-10-31 2021-05-04 中国电信股份有限公司 安全控制方法、安全控制系统、安全控制装置及存储介质
CN113452785A (zh) * 2021-06-28 2021-09-28 平安银行股份有限公司 基于离线资源的服务访问方法、装置、电子设备及介质
EP4086781A4 (en) * 2020-02-04 2022-12-28 Huawei Technologies Co., Ltd. FILE READING METHOD AND TERMINAL

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6216153B1 (en) * 1998-04-23 2001-04-10 Cybersource Corporation Non-extensible thin server that generates user interfaces via browser
US20070028138A1 (en) * 2005-07-29 2007-02-01 Broadcom Corporation Combined local and network storage interface
CN101023401A (zh) * 2004-06-25 2007-08-22 日本电气株式会社 移动终端、移动终端的资源访问控制系统及移动终端中的资源访问控制方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6216153B1 (en) * 1998-04-23 2001-04-10 Cybersource Corporation Non-extensible thin server that generates user interfaces via browser
CN101023401A (zh) * 2004-06-25 2007-08-22 日本电气株式会社 移动终端、移动终端的资源访问控制系统及移动终端中的资源访问控制方法
US20070028138A1 (en) * 2005-07-29 2007-02-01 Broadcom Corporation Combined local and network storage interface

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105897703A (zh) * 2016-03-31 2016-08-24 阔地教育科技有限公司 信息互动方法、信息互动终端、信息互动系统及管理平台
CN112749393A (zh) * 2019-10-31 2021-05-04 中国电信股份有限公司 安全控制方法、安全控制系统、安全控制装置及存储介质
EP4086781A4 (en) * 2020-02-04 2022-12-28 Huawei Technologies Co., Ltd. FILE READING METHOD AND TERMINAL
CN113452785A (zh) * 2021-06-28 2021-09-28 平安银行股份有限公司 基于离线资源的服务访问方法、装置、电子设备及介质

Similar Documents

Publication Publication Date Title
US10708376B2 (en) Message bus service directory
EP3170284B1 (en) Enhanced operations between service layer and management layer in an m2m system by allowing the execution of a plurality of commands on a plurality of devices
WO2014176832A1 (zh) 智能终端管理家庭网关的系统及方法
CN105611422B (zh) 基于多媒体榜单的在线直播方法及装置
US20120017222A1 (en) Interface For Telecommunication Services Using Uniform Resource Identifiers
WO2014194798A1 (zh) 应用分享的方法和装置
JP5753629B2 (ja) モバイルブロードバンドデバイスを管理する方法、デバイス及びシステム
US9338168B2 (en) Method and device for controlling digital living network alliance contents
CA2841140C (en) Rights control method and apparatus for digital living network alliance
WO2008110121A1 (fr) Procédé et système d&#39;adaptation de contenus de services de données, et système de portail
WO2013078918A1 (zh) 登录网络的方法、装置及系统
WO2016065977A1 (zh) 呼叫处理方法、装置、通信终端和服务器
WO2014094240A1 (zh) 一种互联网应用交互方法、装置及系统
WO2012155668A1 (zh) 网管配置管理方法及装置
WO2009062396A1 (fr) Procédé d&#39;accès à des ressources et système d&#39;accès à des ressources
CN112637126B (zh) 一种服务注册方法及Pod
US20140280853A1 (en) Mobile Broadband Device and Method for Processing Mobile Broadband Service of the Mobile Broadband Device
CN103414713A (zh) 一种访问云端媒体资源的方法、装置和dlna设备
WO2012155604A1 (zh) 一种控制数字移动网络联盟内容的方法及装置
WO2013185719A1 (zh) 一种无线上网方法及设备、服务器和无线上网系统
WO2015192497A1 (zh) 通信链路的发送方法、装置及终端
WO2014107956A1 (zh) 一种资源共享方法及装置
CN104980329A (zh) 通讯录管理方法及装置、移动代理服务器
WO2017113355A1 (zh) 服务管理方法、装置、实体及服务开放系统
CN113420001B (zh) 数据共享方法及边缘计算设备

Legal Events

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

Ref document number: 08849715

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08849715

Country of ref document: EP

Kind code of ref document: A1