1. Technical Field
This description generally relates to scanning, additive manufacturing, and subtractive manufacturing.
2. Background
In the field of scanning, additive manufacturing, and subtractive manufacturing, devices often include user interfaces that allow users to control the operations of the respective device. For example, by means of a user interface, a user can select the options for print settings, such as paper size, double-sided printing, color, grayscale, borderless printing, etc.
In one embodiment, a device for communicating with an image-forming device comprises one or more computer-readable media; one or more input interfaces; one or more output interfaces; and one or more processors that are coupled to the one or more computer-readable media, the one or more input interfaces, and the one or more output interfaces, and that are configured to cause the device to perform operations including obtaining a web page from a web server, wherein the web page includes an iframe, populating the iframe with information received from a first image-forming-apparatus-communication application, sending first information from the web page to the iframe, and sending the first information from the iframe to a second image-forming-apparatus-communication application.
In one embodiment, a method for communicating with an image-forming device comprises obtaining a web page from a web server at a browser, wherein the web page includes an iframe and identifies an image-forming-apparatus-communication application; rendering the web page on the browser; populating the iframe with information received from the image-forming-apparatus-communication application; sending first information from the web page to the iframe; and sending the first information from the iframe to the image-forming-apparatus-communication application.
In one embodiment, one or more computer-readable media store instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform operations that comprise obtaining a web page from a web server at a browser, wherein the web page includes an iframe; rendering the web page on the browser; populating the iframe with information received from an image-forming-apparatus-communication application; sending first information from the web page to the iframe; and sending the first information from the iframe to the image-forming-apparatus-communication application.
The following disclosure describes certain explanatory embodiments. Other embodiments may include alternatives, equivalents, and modifications. Additionally, the explanatory embodiments may include several novel features, and a particular feature may not be essential to some embodiments of the devices, systems, and methods described herein.
The server 110 operates a web server 111, which serves a web page 113 that includes resources (e.g., images, a script, and Cascading Style Sheets) and that defines an iframe 114 that is to be populated with information from the IFD-communication application 105. The browser 101 may request a web page 113 that corresponds to the IFD 100 or may identify the IFD 100 for which a web page 113 is requested. Also, the web page 113 or the iframe 114 may identify an IFD 100 or an IFD-communication application 105 that can populate the iframe 114.
The web page 113 may include JavaScript that includes a RESTful API (e.g., the JavaScript is a wrapper for the RESTful API), as illustrated by
The IFD 100 operates a browser 101 that renders the web page 113, including the iframe 114. The iframe 114 and the web page 113 (e.g., a respective script operating on each) communicate with one another, for example by setting the other's URL or by using event messaging. Event messaging may include, for example, posting an event using the JavaScript window.postMessage function. For example, in some embodiments the iframe 114 sends information to the web page 113 by setting the URL of the web page 113, and the web page 113 sends information to the iframe 114 by setting the URL of the iframe 114.
The IFD 100 also operates an IFD-communication application 105 that communicates with the iframe 114. The IFD-communication application 105 may be a dedicated web-server application. Also, the IFD-communication application 105 relays information 142 (e.g., print-job information) between the iframe 114 and the other applications and processes that are running on the IFD 100, for example a multifunctional embedded application platform. Functionally, the IFD-communication application 105 may expose one or more APIs of the IFD 100. Also, the IFD-communication application 105 can communicate with an image server 120, which implements an image-server service and sends one or more images (e.g., documents 143) to the IFD 100. An image can be identified by means of a uniform resource identifier (URI), which may include a uniform resource locator (URL) or a uniform resource name (URN). Also, the image-server service of this embodiment and the other embodiments described herein may serve other types of images (e.g., photographs, graphics, files in an Additive Manufacturing File Format, and files in an STL file format).
Furthermore, depending on the embodiment, the web server 111 that sends the web page to the browser 101 may be hosted on the IFD 100, on a computing cloud, on a dedicated web-server device, or on another computing device. Also, depending on the embodiment, the image (e.g., the document 143) can be stored on a computing cloud, on a remote server, on the IFD 100, or on another computing device. Additionally, even if the web server 111 on the server 110 operates outside of a firewall, an IFD-communication application 105 that operates inside the firewall can still retrieve an image that is stored on a computing device that is inside the firewall (in addition to retrieving images that are stored outside the firewall). Also, in some embodiments the web server 111 does not receive the document's URI or any other information about the document, which may improve security.
Thus, embodiments of the system that is illustrated by
Accordingly, some embodiments of the system enable the development, for devices that have limited capabilities, of web applications that are capable of sending device commands directly to an IFD 100 without going back up through a central server; provide a mechanism for enabling the forming of images that are stored on a website or in a network location; and provide a mechanism for enabling a mobile computing device (e.g., a tablet, and a smart phone) to use the same web application that the IFD 100 uses to display the web page 113 on a front-panel display of the IFD 100, which may give a user the same user experience regardless of the device.
Additionally, the computing devices (i.e., the server 110, the IFD 100, the image server 120) in the embodiment of the system that is illustrated in
Storage/memory includes one or more computer-readable or computer-writable media, for example a computer-readable storage medium. A computer-readable storage medium, in contrast to a mere transitory, propagating signal, includes a tangible article of manufacture, for example a magnetic disk (e.g., a floppy disk, and a hard disk), an optical disc (e.g., a CD, a DVD, and a Blu-ray disc), a magneto-optical disk, magnetic tape, and semiconductor memory (e.g., a non-volatile memory card, flash memory, a solid-state drive, SRAM, DRAM, EPROM, and EEPROM). The storage/memory is configured to store computer-readable data or computer-executable instructions.
For example, to print a requested document (or other image), a user action 391 activates a print control 315 for a requested document on the web page 313. In response to the activation of the print control 315, a script on the web page 313 retrieves the URI of the requested document and sends information that includes a print request, the URI of the requested document, and, in some embodiments, print settings (e.g., duplex print, color, staple, page orientation, and part or all of a PrintTicket), to the iframe 314 by setting the URL of the iframe 314, for example to 123.12.1.1\iframeURL\#printdocumentatURL‘111.1.2.3’,duplexprint=yes. A script operating on the iframe 314 polls for updates to the URL of the iframe 314, detects the new URL, and extracts the information, including the print request. The iframe 314 then sends the request and the other information to an IFD-communication application 305 (e.g., according to an API for the IFD-communication application). The IFD-communication application 305 receives the print request and the accompanying information, and the IFD 300 retrieves the requested document using the document's URI and prints the document. The IFD-communication application 305 may also send a job number to the iframe 314. If the iframe 314 receives a check-status request from the web page 313 for the print job, the iframe 314 uses the job number to request the job's status from the IFD-communication application 305. Upon receiving the job status, the iframe 314 sends the status to the web page 313 by changing the URL of the web page 313, and the web page 313 obtains the status from the updated URL of the web page 313 and updates the web page 313 to display the result.
The flow starts in block 400, where a browser obtains and loads a web page from a web server. The flow then splits into two flows. One flow moves to block 410, where the browser determines if a web-page event (e.g., a message event, or an updated URL) is detected in the web page. An event may be generated, for example, in response to the user activating a control on the web page or by a script that is running on the web page. If no web-page event is detected (block 410=NO), this flow repeats block 410. If an event is detected (block 410=YES), then this flow moves to block 420, where event information (e.g., commands, requests, and messages) is sent from the web page to the iframe (e.g., via the URL, or via a message event). The flow then proceeds to block 430, where the event information is sent from the iframe to an IFD-communication application. Next, in block 440, the IFD performs any services (e.g., forming an image, responding to a status request, and changing output settings), and then this flow returns to block 410.
The other flow moves from block 400 to block 450, where the browser obtains and loads an iframe page that is received from an IFD-communication application. Next, in block 460, the iframe polls an IFD-communication application (which may be the same IFD-communication application that sent the iframe page or a different IFD-communication application) to determine the status of the IFD-communication application. This flow then moves to block 470, where the iframe determines if the status in the IFD-communication application's response indicates that the IFD has information to send to the iframe. If the result of the determination is no (block 470=NO), then this flow returns to block 460. If the result of the determination is yes (block 470=YES), then this flow moves to block 480. In block 480, the iframe obtains the information from the IFD-communication application. Next, in block 490, the iframe sends the information to the web page (e.g., via the URL of the web page, or via a message event). After block 490, this flow returns to block 460.
In this example, the system performs a printing service. When performing the printing service, in stage 1 the browser 601 sends a request for a web page to the web server 611. In stage 2, the web server 611 sends a web page to the browser 601. The web page may include script tag references for JavaScript functions for printing or scanning. In stage 3, the browser 601 receives a print request for a document (or other image) by means of an interface on the web page. Then in stage 4, the browser 611 operates a script on the web page that calls a print function of the iframe and that passes information that includes the URI of the document to the iframe, and the iframe sends a pull-print request and the URI of the document to the IFD-communication application 605. Following, in stage 5, the IFD-communication application 605 uses the URI of the document to obtain the document from the image storage 619, and the IFD 600 begins to perform the operations that are required to print the document. Finally, in stage 6, the IFD-communication application 605 sends print-job-status information to the web page by means of the iframe, and the web page may updates its display to show the print-job-status.
In stage 1, the browser 701 sends a request for a web page to the web server 711. In stage 2, the web server 711 sends a web page to the browser 701, and the browser 701 renders the web page and renders an iframe, which includes populating the iframe with information that is received from the IFD-communication application 705. The web page, the iframe, or both may include script tag references for JavaScript functions for printing or scanning. In stage 3, the web page receives a scan request by means of an interface on the web page, and the web page sends the request to the iframe. Next, in stage 4 the iframe sends the scan request (e.g., via a ScanREST API) to the IFD-communication application 705. Following, in stage 5 the IFD-communication application 705 initiates the performance of a scan by the IFD 700. Then in stage 6, the IFD-communication application 705 sends a URI of the scan job to the iframe, which sends the URI to the web page. The web page (e.g., a script operating on the web page) may use the URI to obtain the scan job and display the scanned document.
Next, in stage 7, the web page receives a send-document request, which identifies a scanned document to send and a location (in this example, the image storage 719) where the document is to be sent, and the web page passes the request to the iframe. In stage 8, the iframe sends the send-document request to the IFD-communication application 705. In stage 9, the IFD-communication application sends the scanned document to the image storage 719. Also, the image storage 719 sends the storage location (e.g., URI, reference ticket) of the scanned document to the IFD-communication application 705. Then in stage 10, the IFD-communication application 705 sends the results of the send-document request, the storage location, or both to the web page by means of the iframe. Some embodiments perform stage 11 and stage 12. In stage 11, the web page sends the storage location to the web server 711. In stage 12, the web server 711 uses the received storage location to retrieve the scanned document from the image storage 719 and sends the scanned document to another storage location.
For example, in some embodiments where the iframe 814 and the web page 813 communicate by setting the URL of the other, to avoid refreshing the entire web page 813 or the entire iframe 814 (which may reset the scripts), when a URL is set it may include a location, for example a hash tag ‘#’ followed by a request or a message. Also, the browser 801 may be configured to not refresh a web page 813 when it receives a URL that includes the hash tag. For example, a request may be formatted as “147.184.16.123/cwiframe/#‘action’:‘print’:printjobURL‘123.34.1.1’”. The requests and messages (e.g., the portion after the hash tag) may be required to obey a specified format. The following is an example of the hash-tag format: http://146.184.16.62:8000/accessible.html?ip=146.184.16.94&scheme=http&port=8000#136133 066081554&{“task”:“print”,“action”:“event”,“eventCallback”:“printStatusUpdate”,“jobStatus”:“printing”}. As illustrated by this example, a hash tag may include different fields (e.g., task, action, eventCallback, and jobStatus) and respective values (e.g., print, event, printStatusUpdate) for the fields. Thus, in some embodiments, scripts (e.g., JavaScript) in the web page 813 and the iframe 814 poll for changes to their respective URL locations, extract requests and messages from the URL locations, perform the requests, and send responses to the messages, if necessary. Also, the iframe 814 sends requests and messages to the IFD-communication application 805 to instruct an IFD to perform requested operations.
Therefore, in some embodiments, even if the web page 813 is received from a web server that operates on a device other than the IFD, the web page 813 allows a user to send messages to the IFD-communication application 805 on the IFD without the messages passing through the web server on the server. In some embodiments, after the web page 813 is received by the browser 801, no additional information needs to be received from the web server on the server.
The second flow may begin in response to an interrupt, a function call, a timer, etc. For example, the second flow may begin in response to the activation of a control on the web page. The second flow starts in block 1020, where information that is to be sent to an iframe is received or determined by a web page. Then the second flow proceeds to block 1025, where the web page generates a URL that includes the information that is to be sent. Finally, the second flow moves to block 1030, where the iframe URL 1099 is changed to the URL that was generated in block 1025. The second flow then ends, although it may be started again.
The third flow starts in block 1040, where an iframe URL 1099 is checked (e.g., by a script that operates on the iframe). The third flow then moves to block 1045, where it is determined if the iframe URL 1099 has been updated. If it is determined that the iframe URL 1099 has not been updated (block 1045=NO), then the third flow returns to block 1040. If it is determined that the iframe URL 1099 has been updated (block 1045=YES), then the third flow moves to block 1050. In block 1050, any messages, requests, commands, or other information are extracted from the iframe URL 1099. The third flow then proceeds to block 1055, where the iframe sends the messages, requests, commands, or other information to the IFD by means of the IFD-communication application, and the IFD performs any actions. The third flow then returns to block 1040.
Finally, the fourth flow may begin in response to an interrupt, a function call, a timer, etc. For example, it may begin in response to being called by a function in the iframe that polls for messages from the IFD-communication application. The fourth flow starts in block 1060, where information that is to be sent to a web page is received (e.g., from an IFD-communication application) by an iframe. Then the fourth flow proceeds to block 1065, where the iframe generates a URL that includes the information that is to be sent. Finally, the fourth flow moves to block 1070, where the web-page URL 1098 is changed to the URL that was generated in block 1065. The fourth flow then ends, though it may be started again.
The second flow may begin in response to an interrupt, a function call, a timer, etc. The second flow starts in block 1120, where information that is to be sent to an iframe is received by a web page. Then the second flow proceeds to block 1125, where the web page generates an iframe event 1197 that includes the information that is to be sent. Finally, the second flow moves to block 1130, where the iframe event 1197 is posted by the web page. For example, the iframe event 1197 may be posted by generating a message event, for example by using window.postMessage. The window.postMessage function creates a message event that is received by the iframe in this flow. The second flow then ends, though it may be started again.
The third flow starts in block 1140, where an iframe (e.g., a script that operates on the iframe) listens for an iframe event 1197. The third flow then moves to block 1145, where it is determined if an iframe event 1197 has been detected. If it is determined that an iframe event 1197 has not been detected (block 1145=NO), then the third flow returns to block 1140. If it is determined that an iframe event 1197 has been detected (block 1145=YES), then the third flow moves to block 1150. In block 1150, any messages, requests, commands, or other information are extracted from the iframe event 1197. The third flow then proceeds to block 1155, where the iframe sends the messages, requests, commands, or other information to the IFD, and the IFD performs any actions. The third flow then returns to block 1140.
Additionally, the fourth flow may begin in response to an interrupt, a function call, a timer, etc. The fourth flow starts in block 1160, where information that is to be sent to a web page is received (e.g., from an IFD-communication application) by an iframe. Then the fourth flow proceeds to block 1165, where the iframe generates a web-page event 1196 that includes the information that is to be sent. Finally, the fourth flow moves to block 1170, where the web-page event 1196 is posted by the iframe. The fourth flow then ends, though it may be started again.
The above-described devices, systems, and methods can be implemented by providing one or more computer-readable media that contain computer-executable instructions for realizing the above-described operations to one or more computing devices that are configured to read and execute the computer-executable instructions. Thus, the systems or devices perform the operations of the above-described embodiments when executing the computer-executable instructions. Also, an operating system on the one or more systems or devices may implement at least some of the operations of the above-described embodiments. Thus, the computer-executable instructions or the one or more computer-readable media that contain the computer-executable instructions constitute an embodiment.
Any applicable computer-readable medium (e.g., a magnetic disk (including a floppy disk, a hard disk), an optical disc (including a CD, a DVD, a Blu-ray disc), a magneto-optical disk, a magnetic tape, and semiconductor memory (including flash memory, DRAM, SRAM, a solid state drive, EPROM, EEPROM)) can be employed as a computer-readable medium for the computer-executable instructions. The computer-executable instructions may be stored on a computer-readable storage medium that is provided on a function-extension board inserted into a device or on a function-extension unit connected to the device, and a CPU provided on the function-extension board or unit may implement at least some of the operations of the above-described embodiments.
The scope of the claims is not limited to the above-described embodiments and includes various modifications and equivalent arrangements. Also, as used herein, the conjunction “or” generally refers to an inclusive “or,” though “or” may refer to an exclusive “or” if expressly indicated or if the context indicates that the “or” must be an exclusive “or.”
This application claims priority to U.S. Provisional Application No. 61/768,312, which was filed on Feb. 22, 2013, which is hereby incorporated by reference.
Number | Date | Country | |
---|---|---|---|
61768312 | Feb 2013 | US |