Patent Application
20050174594
Public areas may include computers and printers that allow users to print desired files, images, or other objects. When a print job is submitted to a public printer, the print job is typically printed automatically, for example, based on the order it was received. The user can then retrieve the printed job from the printer. However, printed jobs may remain in the open and accessible for other people to see and/or take. In some environments, a printer may be maintained behind a counter and the user is required to pay for a print job before the printed job can be retrieved from the personnel operating the printer. However, print jobs may be printed and abandoned without receiving payment, thereby wasting the resources of the printer.
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate various example systems, methods, and so on that illustrate various example embodiments of aspects of the invention. It will be appreciated that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one example of the boundaries. One of ordinary skill in the art will appreciate that one element may be designed as multiple elements or that multiple elements may be designed as one element. An element shown as an internal component of another element may be implemented as an external component and vice versa. Furthermore, elements may not be drawn to scale.
The following includes definitions of selected terms employed herein. The definitions include various examples and/or forms of components that fall within the scope of a term and that may be used for implementation. The examples are not intended to be limiting. Both singular and plural forms of terms may be within the definitions.
“Computer-readable medium”, as used herein, refers to a medium that participates in directly or indirectly providing signals, instructions and/or data. A computer-readable medium may take forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media may include, for example, optical or magnetic disks and so on. Volatile media may include, for example, optical or magnetic disks, dynamic memory and the like. Transmission media may include coaxial cables, copper wire, fiber optic cables, and the like. Transmission media can also take the form of electromagnetic radiation, like those generated during radio-wave and infra-red data communications, or take the form of one or more groups of signals. Common forms of a computer-readable medium include, but are not limited to, a floppy disk, a flexible disk, a hard disk, a magnetic tape, other magnetic medium, a CD-ROM, other optical medium, punch cards, paper tape, other physical medium with patterns of holes, a RAM, a ROM, an EPROM, a FLASH-EPROM, or other memory chip or card, a memory stick, a carrier wave/pulse, and other media from which a computer, a processor or other electronic device can read. Signals used to propagate instructions or other software over a network, like the Internet, can be considered a “computer-readable medium.”
“Data store”, as used herein, refers to a physical and/or logical entity that can store data. A data store may be one or more of, for example, a database, a table, a file, a list, a queue, a heap, a memory, a register, and so on. A data store may reside in one logical and/or physical entity and/or may be distributed between two or more logical and/or physical entities.
“Logic”, as used herein, includes but is not limited to hardware, firmware, software and/or combinations of each to perform a function(s) or an action(s), and/or to cause a function or action from another component. For example, based on a desired application or needs, logic may include a software controlled microprocessor, discrete logic like an application specific integrated circuit (ASIC), a programmed logic device, a memory device containing instructions, or the like. Logic may also be fully embodied as software. Where multiple logical logics are described, it may be possible to incorporate the multiple logical logics into one physical logic. Similarly, where a single logical logic is described, it may be possible to distribute that single logical logic between multiple physical logics.
An “operable connection”, or a connection by which entities are “operably connected”, is one in which signals, physical communication flow, and/or logical communication flow may be sent and/or received. Typically, an operable connection includes a physical interface, an electrical interface, and/or a data interface, but it is to be noted that an operable connection may include differing combinations of these or other types of connections sufficient to allow operable control. For example, two entities can be operably connected by being able to communicate signals to each other directly or through one or more intermediate entities like a processor, an operating system, a logic device, software, or other entity. Logical and/or physical communication channels can be used to create an operable connection.
“Signal”, as used herein, includes but is not limited to one or more electrical or optical signals, analog or digital signals, data, one or more computer or processor instructions, messages, a bit or bit stream, or other means that can be received, transmitted and/or detected.
“Software”, as used herein, includes but is not limited to, one or more computer or processor instructions that can be read, interpreted, compiled, and/or executed and that cause a computer, processor, or other electronic device to perform functions, actions and/or behave in a desired manner. The instructions may be embodied in various forms like routines, algorithms, modules, methods, threads, and/or programs including separate applications or code from dynamically linked libraries. Software may also be implemented in a variety of executable and/or loadable forms including, but not limited to, a stand-alone program, a function call (local and/or remote), a servelet, an applet, instructions stored in a memory, part of an operating system or other types of executable instructions. It will be appreciated by one of ordinary skill in the art that the form of software may be dependent on, for example, requirements of a desired application, the environment in which it runs, and/or the desires of a designer/programmer or the like. It will also be appreciated that computer-readable and/or executable instructions can be located in one logic and/or distributed between two or more communicating, co-operating, and/or parallel processing logics and thus can be loaded and/or executed in serial, parallel, massively parallel and other manners.
Suitable software for implementing the various components of the example systems and methods described herein include programming languages and tools like Java, Pascal, C#, C++, C, CGI, Perl, SQL, APIs, SDKs, assembly, firmware, microcode, and/or other languages and tools. Software, whether an entire system or a component of a system, may be embodied as an article of manufacture and maintained as part of a computer-readable medium as defined previously. Another form of the software may include signals that transmit program code of the software to a recipient over a network or other communication medium. Thus in one example, a computer-readable medium has a form of signals that represent the software/firmware as it is downloaded from a web server to a user. In another example, the computer-readable medium has a form of the software/firmware as it is maintained on the web server. Other forms may also be used. It will be appreciated that components described herein may be implemented as separate components or may be combined together.
“User”, as used herein, includes but is not limited to one or more persons, software, computers or other devices, or combinations of these.
Some portions of the detailed descriptions that follow may be presented in terms of algorithms and symbolic representations of operations on data bits within a memory. These algorithmic descriptions and representations are the means used by those skilled in the art to convey the substance of their work to others. An algorithm is here, and generally, conceived to be a sequence of operations that produce a result. The operations may include physical manipulations of physical quantities. Usually, though not necessarily, the physical quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a logic and the like.
It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, instructions, symbols, characters, terms, numbers, or the like. It should be borne in mind, however, that these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, it is appreciated that throughout the description, terms like processing, computing, calculating, determining, displaying, or the like, refer to actions and processes of a computer system, logic, processor, or similar electronic device that manipulates and transforms data represented as physical (electronic) quantities.
Described herein are example systems, methods, computer-readable media, print drivers, graphical user interfaces, and other embodiments associated with identifying and/or charging for print jobs. In one example system, print jobs/requests can be parked or otherwise delayed in an image forming device until they are claimed by their owner. To have a print request actually printed, a user can provide a credit card or other identification device to the image forming device in order to claim the print request. Providing the card indicates to the system that the user is physically present and is requesting to retrieve their print request. The data from the credit card can be used to identify delayed print requests that belong to the user and may also be used to pay for the print request by charging the credit card. The credit card data, for example, such as the user's name or last four digits of their card number, can be used to match identity information associated with each print request.
For image forming devices that are in a public venue, print requests are not printed until the owner physically claims the print request by swiping his/her credit card at the printer, or by providing other types of identification information. This may assist with security issues where printed documents are not printed for anyone to see or take, but rather, are printed when the owner is physically in the presence of the image forming device and is ready to retrieve his/her printed job. Additionally, by using a credit card or other card with charge account information, the image forming device can charge for the services of processing the print request by charging the credit card. Thus, in one example, identifying and charging for print requests can be performed in response to one action from a user such as a single data input (e.g. single swipe of a credit card). The single data input serves as both identifying information and charging information.
Illustrated in
A print delay logic 105 can be configured to handle incoming print requests 110. The print requests 110 are initially held up and may be maintained in a pending state as delayed print requests 115. For example, the delayed print requests 115 can be held in a queue until they are claimed or retrieved by their owner. In that regard, an input device 120 can be provided that is configured to receive claim request data 125 from a user. The claim request data 125 can be any type of identification information such as a user's name and/or other identification information that can be used to associate the user to his/her delayed print request(s) 115. It is presumed that the delayed print request(s) 115 includes corresponding identification information that allows for the information to be compared with the claim request data 125. The configuration of the delayed print request(s) 115 will be described in greater detail below.
In one example, the input device 120 can be a magnetic card reader and the claim request data 125 can be the information obtained from a card read by the input device 120. Once the claim request data 125 is received, an identification logic 130 can be configured to match the claim request data 125 with identification data associated with each of the delayed print requests 115. Thus, the identification logic 130 can be configured to identify one or more print requests for which the user that inputted the claim request data 125 is an owner. The pending print request(s) belonging to the user are identified in
It will be appreciated that the claim request data 125 may include more information than is necessary in order to identify a matching print request. For example, a credit card swiped in the input device 120 may provide a set of data but, the identification logic 130 may only use selected portions or sub-sets of the data in order to identify and associate with a matching print request. If a match is found, the identification logic 130 can be configured to cause the identified one or more delayed print requests to be processed by the image forming device into a printed job. In this manner, print requests can be delayed until physically claimed by a user so that documents are not printed until the user is physically present to retrieve the printed documents. It will be appreciated that when each of the print requests 110 are generated, owner identification is received from the user and associated with each print request so that the owner information can be used to match against the claim request data 125. Generating print requests will be described in greater detail below.
With further reference to
In another example, the input device 120 can include a key pad configured to allow a user to input an identification code such as a password, that can become part of the claim request data 125. The key pad can be used in combination with the card reader. Each delayed print request 115 can include owner identification that allows the identification logic 130 to compare the identification code (provided by the user) to the owner identification of each print request 115 to determine a match. If there is a match, the delayed print request 115 then becomes a claimed print request(s) 135 that can be sent for processing into a printed output. It will be appreciated that a data store can be used to maintain the delayed print requests 115 in any desired computer-readable medium, like a memory, within an image forming device.
Illustrated in
In the flow diagrams, blocks denote “processing blocks” that may be implemented with logic. A flow diagram does not depict syntax for any particular programming language, methodology, or style (e.g., procedural, object-oriented). Rather, a flow diagram illustrates functional information one skilled in the art may employ to develop logic to perform the illustrated processing. It will be appreciated that in some examples, program elements like temporary variables, routine loops, and so on are not shown. It will be further appreciated that electronic and software applications may involve dynamic and flexible processes so that the illustrated blocks can be performed in other sequences that are different from those shown and/or that blocks may be combined or separated into multiple components. It will be appreciated that the processes may be implemented using various programming approaches like machine language, firmware, procedural, object oriented and/or artificial intelligence techniques. The various actions illustrated and/or described herein can occur in serial, but also various actions could occur substantially in parallel.
With reference to
In response to receiving the physically inputted claim data, the process can determine which pending print requests belong to the user (Block 210). If the inputted claim data matches with a pending print request, the print request becomes a claimed print request and is selected for processing into a printed output (Block 215). Optionally, if one or more print requests are validly claimed, the claimed print requests can be displayed to the user and the user may be allowed to selectively initiate printing of the print request that belongs to them.
It will be appreciated that the methodology 200 and the other methodologies described herein can be embodied as processor-executable instructions provided by a computer-readable medium. For example, processor-executable instructions can be provided that are configured to cause an image forming device, a computing device, or other logic to process print requests as described herein. The processing may include receiving a print request that includes an associated user identification; delaying the processing of the print request in the image forming device until the request is claimed by a user; and in response to receiving claim data from a user in the presence of the image forming device (e.g. physically inputting identification data), and the claim data can be compared with the user identification associated with the delayed print request. The print request can then be processed if the user identification matches the claim data.
The process 200 may also include maintaining the received print requests in a queue where the print requests are received from one or more sources and/or one or more users. Additionally, the process may be configured so that a user account can be automatically charged for the claimed print request based on the claim data received. As described previously, the claim data may include credit card or other charge account information that can be used to charge for the printing services of the image forming device. Optionally, the process may also perform a pre-authorization on a user account identified by the claim data prior to processing the print request. For example, a verification can be performed to validate that the user account is valid and has sufficient funds or charge limits available to cover the costs of printing the claimed print request(s).
Illustrated in
The client 305 can include a print driver 310 configured to process print requests for a user. For example, the print driver 310 can include logic configured to generate a print request based on a selected data that is desired to be printed. The selected data can be, for example, a document, an image, a file, or other type of object that can be printed. The print driver 310 may also include logic configured to obtain, from the user, owner identification data to be embedded into the print request. For example, the print driver 310 may request a user's name, credit card information, other identification information, a password, and/or any combination of these. In the following example, it will be assumed that credit card information is used. The owner information (e.g. credit card information) can then combined or otherwise associated with the print request and transmitted to the image forming device 300.
As print requests are received by the image forming device 300, the print requests are delayed or otherwise maintained in a pending state until physically claimed by the user, for example, by providing claim data to the image forming device 300. The claim data will be used to match against the owner identification data in the pending print requests to determine ownership. A card reader 315 can be connected to the image forming device 300 where the card reader 315 is configured to accept or receive claim data or other type of identification data from a user. For example, the card reader 315 can be a credit card reader where a user can swipe a credit card 320 and the credit card data is used as claim data by the image forming device 300. By detecting a swipe of the credit card, the image forming device 300 can ensure that the user is physically present.
The credit card data can then be used to compare with the owner identification data embedded in pending print requests to determine if there is a match. If a match is found, meaning that the user who swipes the credit card 320 is the same user that initiated the print request on the client 305, the claimed print request is then processed into a printed output 325. In this example, the owner identification data inputted into the print driver 310 would include, for example, the user's name, the user's credit card number, selected portions or sub-sets of the credit card number (e.g. the last four digits), or other selected data that would be contained on the credit card so that a match can be determined. In another example, the user who claims the print request may not be the same user that generated the print request but may be an authorized agent, a co-owner of the credit card, and the like. In another example configuration, the logic to perform above-described processing and the card reader 315 may be local to a print server (not shown) that is in communication with the image forming device 300.
Illustrated in
The process may include charging a flat fee for printing services, dynamically determining the cost of each print request, or using other types of cost calculating algorithms. For example, a print request may indicate the number of pages included in the request. The cost can then be calculated based on the number of pages and charged to the credit card. The process may also include verifying that the credit card is valid and/or has appropriate funds or limits before charging the account. It will be further appreciated that the credit card can be other types of cards that allow for the charging of an account.
Illustrated in
As print requests 505 are received, a print delay logic 520 can be configured to delay the processing of each print request by placing the print request in the data store 510 until it is claimed by an owner of the print request. An input device 525 such as a card reader can be provided and configured to read a credit card that is provided by a user who wishes to claim a pending print request. Optionally, a key pad can also be used to receive additional identification data that can be combined with credit card data, if desired. If successfully claimed, the print request can then be initiated for printing. The credit card data is one example of user data 530 that can be inputted into the input device 525 in order to claim a pending print request 510.
When the user data 530 is received, this event indicates that a user is physically present and is attempting to claim a print request. In response, an identification logic 535 can be configured to identify which of the pending print requests 510 in the data store are owned by the user by comparing the user data 530 (e.g. credit card data) with the owner information associated with the print requests, for example, the owner ID from the table 515. If a match is found, the associated pending print request can be selected for processing.
Optionally, a payment logic 540 may also be provided that is configured to charge the credit card read by the input device 525 for the services performed by the image forming device. An imaging logic 545 can be configured to cause the image forming device to print the matched print request(s) identified by the identification logic 535. This may include, for example, sending the matched print request to an imaging mechanism to be printed into a hard copy. As another example, the print request processing system 500 may include a display (not shown) configured to display the matched print requests that were identified as owned by the user using a graphical user interface.
Illustrated in
In one example, the print request processing system 605 can be operated using a chai service 615 that is configured to execute logic or instructions, communicate with network devices, and communicate with a card reader 620 or other type of input device that can receive data from a user. The image forming device 600 can operate to delay processing of print requests until claimed by a user in one or more of the ways previously described. In another example, the image forming device 600 can be configured with a Linux box chaiwood server that is configured to control the operation of the card reader 620, control the operation of the print request processing system 605, and also perform communications with network devices or other external devices instead of having the chai service 615.
In one example, the chai service 615 can be a virtual machine configured to interpret and execute Java-like code. The chai service 615 can be configured to run chai servelets that perform desired functions associated with the processing of the print requests, as described, including the identification functions and/or charging functions. In another example, the Linux box chaiwood server 625 may be a computer or server connected to the image forming device 600 where the chaiwood server 625 is configured to receive print jobs and read identification card data and otherwise perform the functions of the print request processing system as described.
Illustrated in
Illustrated in
The print driver 800 can include logic to request identification information and/or billing information from a user and then inject or otherwise associate the identification information with the print request. This may be performed, for example, using a printer job language to embed attributes of the identification information. The identification attributes can be configured as meta data that is positioned in front of the print request data before it is sent to a printer. When received by the printer, the processing system can extract the meta data and store the meta data for subsequent identification with a user wishing to claim a print request. If a received print request does not include the appropriate meta data, the print request can be discarded and/or segregated for special processing. A received print request that has the appropriate meta data or other configuration is then configured to be maintained in a pending state in the image forming device until physically claimed by the user by providing a claim data to the image forming device that matches the owner identification data 810. The claim data can include identification information to identify the print request and charging information to charge a user account for processing the print request.
It will be appreciated that any of the described image forming devices, computing devices, logics, and print request processing systems can be configured to discard invalid print requests. For example, an invalid print request may be one that does not include owner identification/charge data, or a print request that includes data that cannot be recognized by the print request processing system. Invalid print requests may also be held separately for special identification and/or processing.
The following is an example application and scenario where the presently described embodiments may be implemented and used. For example, a user wishes to print a document from a computer. The computer is connected to a printer that is in a public location such as a library or coffee shop. Before submitting the print request, the computer obtains identity information from the user such as a name and/or credit card information. The identity information is combined with the print request and submitted to a print server or to the printer where the print request is held in a pending state. The user then walks over to the print server or printer and swipes their credit card in order to claim and retrieve their print request. The data read from the credit card is used to identify the user's pending print request, charge the credit card for printing services, and the print request is processed into a printed document. By having the user physically present to retrieve their print request, it may reduce the chances that the printed document is stolen or viewed by unauthorized people. Additionally, by not printing a print request until physically claimed, the resources of the printer can be better controlled by not permitting unauthorized print requests to be processed and by ensuring that services will be paid for.
While example systems, methods, and so on have been illustrated by describing examples, and while the examples have been described in considerable detail, it is not the intention of the applicants to restrict or in any way limit the scope of the appended claims to such detail. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the systems, methods, and so on described herein. Additional advantages and modifications will readily appear to those skilled in the art. Therefore, the invention, in its broader aspects, is not limited to the specific details, the representative apparatus, and illustrative examples shown and described. Accordingly, departures may be made from such details without departing from the spirit or scope of the applicants' general inventive concept. Thus, this application is intended to embrace alterations, modifications, and variations that fall within the scope of the appended claims. Furthermore, the preceding description is not meant to limit the scope of the invention. Rather, the scope of the invention is to be determined by the appended claims and their equivalents.
To the extent that the term “includes” or “including” is employed in the detailed description or the claims, it is intended to be inclusive in a manner similar to the term “comprising” as that term is interpreted when employed as a transitional word in a claim. Furthermore, to the extent that the term “or” is employed in the claims (e.g., A or B) it is intended to mean “A or B or both”. When the applicants intend to indicate “only A or B but not both” then the term “only A or B but not both” will be employed. Thus, use of the term “or” herein is the inclusive, and not the exclusive use. See, Bryan A. Garner, A Dictionary of Modern Legal Usage 624 (2d. Ed. 1995).
