DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on May 31, 2026 has been entered.
Response to Amendment
3. Claims 19, 35 and 36 have been amended. Claim 19-38 are presented for examining.
Response to Arguments
4. Applicant’s arguments, filed May 31, 2026, with respect to the rejection of claims 19 under 35 U.S.C. § 103 have been fully considered but are not persuasive. The rejection has been modified in this Office Action: Markin is no longer relied upon, and claim 19 is rejected under 35 U.S.C. § 103 over Baubert in view of Martin and Jain. Applicant’s argument are addressed below.
5. Applicant argues that the combination teaches only a client-side (on-device) solution - including that Jain's neural network resides on the mobile device - and that the references lack the claimed server-side control architecture, live video session, and real-time autocapture loop. The arguments are not persuasive because the relied-upon teachings of Martin and Jain are server-side and disclose each amended feature.
Baubert in view of Martin and Jain teaches every limitation of amended claim 19. The non-amended limitations are taught as set forth in the rejection below. As to the amended limitations:
(1) the server processing the frames using a neural network to detect the identification document and evaluate image quality is taught by Martin (server analyzes the video “frame by frame,” detects the document, and scores quality) in view of Jain (server-side trained neural network);
(2) communicating unsatisfactory quality based on the server’s response is taught by Martin (“feedback for improving quality of an image”);
and (3) the automatic capture of the sufficient-quality frame is taught by Martin’s server-side selection - “the server identifies a particular frame … and provides data to the mobile device that the server captured an image … of sufficient quality.” To the extent the claim recites the front-end software functionality (rather than the server) performing the capture in response to the server’s trigger, Applicant’s own specification discloses that allocation as interchangeable (approved image “sent directly to … BOS … [a]lternatively … to the front-end SDK,” [0136]); that limitation is separately addressed under 35 U.S.C. 112(b) and is treated here as best understood.
The relied-upon teachings are server-side, not client-side. Martin is a server-side architecture - the mobile device captures and transmits, and the server performs the detection, quality evaluation, and frame selection (“the mobile device may provide the video to a server [0025] and [0040]; the server may analyze the video frame by frame [0025]; the server … provides data to the mobile device” [0026]). Jain is not limited to a device-resident neural network; the device-resident embodiment on which Applicant relies is merely an alternative, and Jain expressly discloses the neural network residing on, and the analysis performed by, the remote server [col. 10 line 1-21 col, 16 line 45-67 & col. 17 line 1-7]. A reference must be considered for all that it teaches, including alternative embodiments. See MPEP § 2123.
Martin teaches a live video session (“the one or more images of the document are frames of a video”) and a real-time loop that continuously captures and scores frames and automatically completes the capture when a sufficient-quality frame is found (“the capture method continues and captures another frame … if a likely good capture is detected … the capture is complete”), with the server identifying the sufficient-quality frame and signaling the device. The combination thus teaches the claimed client-server control flow — front end transmits frames; server evaluates with a neural network and identifies/selects the satisfying frame; front end is signaled and communicates the result. The front-end-vs-server allocation of the final capture is disclosed by Applicant as interchangeable ([0130], [0136] and [0145] and is separately addressed under 35 U.S.C. 112(b). The rejection is maintained as modified herein.
Claim Rejections - 35 USC § 112
6. The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
7. Claims 19-38 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
8. “the image” - lack of antecedent basis (claims 19, 35, 36, and 20-34, 37, 38). Claim 19 recites “communicates to the user that the image is of unsatisfactory quality.” There is insufficient antecedent basis for this limitation. Claim 19 recites “a plurality of frames,” “the plurality of frames,” “the frames,” and “a selected frame,” but does not recite “an image.” The recitation “at least one image,” which had provided antecedent basis for “the image,” was canceled by the amendment filed . Therefore, it cannot be determined to which image “the image” refers (e.g., one of the plurality of frames, the selected frame, or another image). For purposes of examination, “the image” is interpreted as a frame of the plurality of frames captured from the live video session. Independent claims 35 (computer program product) and 36 (computer system) recite the method of claim 19 and are rejected for the same reason. Claims 20-34, 37 and 38 depend from claim and incorporate the indefinite limitation, and are rejected for the same reason.
9. “ the session ” - ambiguous antecedent (claims 23, 24, 25, 26, 27, 37 and 38). Claim 19 recites two sessions: “an identity verification session” and “a live video session.” Claims 23-27 and 38 each recite “during the session,” and claim 38 recites “said session” and “session termination,” without identifying which of the two sessions is intended. Because two different sessions are recited, the recitation is indefinite. The “live video session” was added by the amendment filed May 31, 2026. For purposes of examination, “the session” and “said session” are interpreted as the identity verification session.
10. Inconsistency with amended claim 19 - location of processing/detection (claims 23, 24, 25 and 37). Each of claims 23, 24, 25 and 37 recites “wherein the software functionality processes at least one image captured by at least one end-user’s cellphone during the session, and for at least one image so captured, detects that the image is of [unsatisfactory/satisfactory] quality.” Amended claim 19 recites that “the server processes the plurality of frames using a neural network to detect … whether the frames satisfy [the] image quality checks,” and that the software functionality merely “communicates” the result based on a response received from the server. It is therefore unclear whether the detection of image quality is performed by the server (claim 19) or by the software functionality (these dependent claims), and how the “at least one image” recited in these claims relates to the “plurality of frames” and “selected frame” recited in claim 19. The metes and bounds of these claims cannot be ascertained.
11. Inconsistency - claim 27. Claim recites that “the software functionality captures an image uploaded by the user.” Amended claim 19 recites that the software functionality “automatically captures a selected frame from the live video session without requiring manual user capture intervention.” It is unclear whether the user-uploaded image of claim 27 is consistent with, additional to, or in conflict with the automatic capture without manual intervention recited in claim 19. Claim 27 is therefore indefinite.
12. Auto-capture - front end vs. server (claims 19, 35, 36, and dependents reciting the auto-capture limitation). Claim 19 recites that “the software functionality” automatically “captures a selected frame from the live video session … in response to receiving a trigger from the server indicating that the selected frame satisfies the one or more image quality checks.”
The metes and bounds of this limitation cannot be determined. The plurality of frames are captured by the front end and transmitted to the server before evaluation, and the server is the only entity that evaluates the frames and identifies the frame satisfying the quality checks. It is therefore unclear how, or whether, the front-end software functionality “captures a selected frame from the live video session” after the server’s evaluation: the recited frame was already captured (in order to be transmitted), and the specification discloses that, upon approval, the server sends the approved image to the front end ([0136]: the approved image “may be sent directly to … BOS … [a]lternatively … to the front-end SDK”), such that the front end receives the image rather than capturing it. The specification is further internally inconsistent, describing the front-end SDK “captur[ing] the image” ([0130]), the approved frame being “selected by the front-end SDK” ([0145]), and the back end “send[ing] … to the front-end SDK” ([0136]). It is thus unclear whether the recited “captures a selected frame” is performed by the front end or by the server, whether it refers to a new capture or to one of the already-transmitted frames, and how the front end captures the specific server-approved frame “from the live video session” in response to a trigger when that frame has already been captured and transmitted. Dependent claim 38 separately recites “autocapture of the ID if ID is detected and all quality checks are good” without specifying which entity performs the autocapture, compounding the same indefiniteness. Claims 35 and 36, and the dependent claims incorporating the auto-capture limitation, are rejected for the same reasons.
Claim Rejections - 35 USC § 103
13. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
14. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
15. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
16. Claims 19, 21-24, 28, 29, 31, 32 and 35-37 are rejected under 35 U.S.C. § 103 as being unpatentable over Baubert et al. (US 9,875,511 B1), hereafter Baubert, in view of Martin (US 2017/0344824 A1), hereafter Martin, and further in view of Jain et al. (US 10,242,283 B1), hereafter Jain.
Noted that indicates what the cited art does not teach.
Regarding claim 19, Baubert teaches a method supporting identity verification for an end-user, the method comprising: {Baubert [Col. 2, line 27-28] “Methods for invoking an image capture device using a desktop computer are provided.” [Col. 4, line 27-37] “The web server computer 106 comprises a data collection application 108 that communicates with the particular application to the computer device 102. The data collection application 108 performs one or more tasks, including conducting transactions that may require a copy of a document 122. Examples of such transactions include identity verification.”} Images uploaded via Baubert’s method could be used in an identity verification transaction and therefore, Baubert’s method supports identity verification for an end user. Noted that to the extent the preamble is limiting, the identity-verification is further taught by Martin, below.
sending a link to an end-user's mobile phone, wherein said link directs an end-user to a software functionality comprising a front-end system, which is operative for end-user identity verification, thereby to open an identity verification session when the end-user clicks on the link; {Baubert [Col. 4, line 17-21, Fig. 4] “The application can instruct the web server computer to send a link to the mobile computer device.” [Col. 4 line 59 - Col. 5 line 16] “The web server computer 106 generates a URL that is accessible using a browser of a mobile computer device 110. The URL is parameterized to invoke a server-side function that is programmed to cause capturing an image of the document 122 that was requested, at the mobile computer device 110. The URL may be associated with the session identifier and/or line item identifier.” [Col. 7 line 26-29, Figs. 5A & 5B] “In an operation 206, the mobile computer device 110 receives the URL from the data collection application 108. Using the messaging application 112, the mobile computer device 110 displays the URL or a link to the URL.” [Col. 7, line 39-41] “Via the messaging application 112, the mobile computer device 110 selects the URL by, for example, taping on the URL via a touchscreen.” [Col. 7, line 42-58] “In an operation 208, the messaging application 112 invokes the browser 114 on the mobile computer device 110. The browser may display a webpage associated with the URL.”} As disclosed in Baubert, when a user taps on the link (i.e., URL), the user is directed to a browser of a mobile device, and thereby opening a session. The browser displays a webpage that allows users to upload an image and then sends it to a web server (see col. 8, line 67-col. 9 line 1).
and via the software functionality activated by the end-user's clicking on the link, eliciting data from the end-user, by initiating a live video session; {Baubert [Col. 4 line 59 - Col. 5 line 16] “The URL comprises an HTML 5 media capture field that, when selected by the mobile computer device 110, causes invoking a camera application of the mobile computer device 110 that is coupled to and operates with a camera in the mobile computer device.” [Col. 8, line 17-25 ] “In an operation 212, the browser 114 invokes the camera application 116. The user can then use the camera application 116 to instruct the camera 118 to capture an image of the document.”} The URL, when selected, invokes the camera application of the smartphone device, and the front end being a website/browser application accessible without installation of a dedicated application (col. 9, line 39-45).
However, Baubert does not teach wherein said link directs an end-user to a software functionality comprising a front-end system, which is operative for end-user identity verification, thereby to open an identity verification session when the end-user clicks on the link; and via the software functionality activated by the end-user's clicking on the link, eliciting data from the end-user by initiating a live video session; wherein the software functionality sends a plurality of frames captured from the live video session to a server for evaluation,
wherein the server processes the plurality of frames using a neural network to detect whether an identification document is present and whether the frames satisfy one or more image quality checks; and wherein the software functionality communicates to the end-user that the image is of unsatisfactory quality based on a response received from the server, and automatically captures a selected frame from the live video session without requiring manual end-user capture intervention in response to receiving a trigger from the server indicating that the selected frame satisfies the one or more image quality checks.
However, Martin teaches and via the software functionality activated by the end-user's clicking on the link, eliciting data from the end-user by initiating a live video session; -- Martin teaches that “a camera … may capture video” and that “the one or more images of the document are frames of a video” (Martin, [0009], [0012], [0024] and 0025]).
wherein the software functionality sends a plurality of frames captured from the live video session to a server for evaluation, -- Martin teaches that “the mobile device may provide the video to a server (Martin [0025], [0040]); the server may analyze the video frame by frame” (Martin, [0025]).
wherein the server processes the plurality of frames using a neural network to detect whether an identification document is present and whether the frames satisfy one or more image quality checks. – As to the image checks, Martin teaches that the server evaluates image quality against thresholds (focus, border-fit, and expected-shape scores), and identifies a frame of sufficient quality identifying a frame of sufficient quality (Martin, [0012], [0025], [0027] and [0035] and [0036]).
and wherein the software functionality communicates to the end-user that the image is of unsatisfactory quality based on a response received from the server, Martin teaches that, where the quality fails the threshold, the system provides “feedback for improving quality of an image of the document” to the user, and the mobile device displays the server’s determination (Martin, [0012], [0038]).
and automatically captures a selected frame from the live video session without requiring manual end-user capture intervention in response to receiving a trigger from the server indicating that the selected frame satisfies the one or more image quality checks. Martin teaches server-side automatic selection/capture of the sufficient-quality frame: “the server identifies a particular frame of the video and provides data to the mobile device … that the server captured an image of the identification card … of sufficient quality” (Martin, [0026]). To the extent the claim is understood to require the front-end software functionality (rather than the server) to perform the capture in response to the server’s trigger, Applicant’s own specification discloses that the allocation as interchangeable – the approved image “may be sent approved image “may be sent directly to … BOS … [a]lternatively … to the front-end SDK” ([0136]). (This limitation is separately rejected under 35 U.S.C. 112(b); it is treated here as best understood.)
Baubert and Martin are analogous art, each being directed to capturing an image of a document using a user’s mobile device and each reasonably pertinent to the inventor’s problem of acquiring a document image via a mobile device for server-side processing. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to deliver Martin’s website-based identity-document capture front end to the user’s mobile phone using Baubert’s SMS-link/HTML5 no-installation mechanism. Martin already contemplates directing the user to a website that requests capture of the identification document (Martin [0024]), and Baubert provides a known, convenient mechanism for delivering such a front end without app installation, reducing complexity and user error. Doing so would enable “perform[ing] document authentication only on images of documents that are of sufficient quality”(Martin, para. 0014), and “decrease computing resources needed for document authentication, such as processing power and battery power” (Martin, para. 0014).
However, Martin also does not teach wherein the server processes the plurality of frames using a neural network to detect whether an identification document is present and whether the frames satisfy one or more image quality checks.
However, Jain teaches wherein the server processes the plurality of frames using a neural network to detect whether an identification document is present and whether the frames satisfy one or more image quality checks; Jain teaches performing the above server-side identification-document image evaluation using a trained neural network: Jain discloses “a neural network having a trained model based on a history of acceptances and/or rejections of previously submitted ID images” (Jain, col. line 54-59); that the neural network detects image-quality -features and an improper or “wrong type of ID” (Jain, col. 1, line 47-53, col. 11 line 59-67, col. 12 line 1-4); and that “the bulk of the image analysis (including image evaluation with the neural network) may be done by the remote pre-validation web server” (Jain, col. 10 line 1-21 col, 16 line 45-67 & col. 17 line 1-7). As further evidence that detecting whether an identification document is present was known, Markin (US 2018/0253602 A1) discloses a gateway that determines whether an incoming image “is an ID image or not” ([0041], [0061]).
Jain is analogous art because each of Baubert, Martin and Jain pertains to processing an image of a document captured using a user’s mobile device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert and Martin to detect whether an ID document is present and to evaluate image quality using a trained neural network, as taught by Jain, because Jain teaches that use of a trained neural network for the same server-side ID-image evaluation “eliminate[s] the necessity of having insight into the acceptance/rejection criteria” (Jain, col. 1, line 59-62) and improves the speed and efficiency of the verification process (Jain, col. 4, line 47-49). Incorporating Jain’s trained neural network into the server side detection and quality evaluation is the use of a known technique to improve a similar method in the same way to yield predictable results.
Claim 21:
Regarding claim 21, Baubert, Martin and Jain teach the elements of claim 19 as stated.
However, Baubert does not teach wherein said data comprises an image of at least a portion of an ID document borne by the end-user.
However, Martin teaches wherein said data comprises an image of at least a portion of an ID document borne by the end-user. {Martin [Para. 0040] “The system received one or more images of a document (310). The document is an identification document (e.g., driver's license, passport, etc.).” [Para. 0050] “The process described in this application is designed to take real time video input and detect driver's license cards in the field of view. The detected licenses are segmented from the image and returned in at in a standard rectangular format at the requested resolution along with quality metrics to determine the suitability for further processing.”}
Martin is analogous art because each of Baubert, Martin and Jain pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert and Jain to include Martin’s teaching of capturing a an image of an ID document borne by an end-user. Doing so would enable “perform[ing] document authentication only on images of documents that are of sufficient quality”(Martin, para. 0014), and “decrease computing resources needed for document authentication” (Martin, para. 0014).
Claim 22:
Regarding claim 22, Jain teaches the elements of claim 21 as outlined above.
However, Baubert and Martin do not teach wherein said at least portion of the ID document includes the front and back sides of the ID document.
However, Jain teaches wherein said at least portion of the ID document includes the front and back sides of the ID document. {Jain [Col 4, line 56-66 ] (24) “FIG. 1A depicts an example scenario in which a digital image 108 of the front of an ID card 106 is captured by a user's mobile computing device 102.” [Col 5, line 18-33 ] “FIG. 1B depicts a similar example scenario… in which a digital image 118 of the back of an ID card 116 is captured by a user's mobile computing device 102.”}
Jain is analogous art because each of Baubert, Martin and Jain pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert and Martin to include Jain’s teaching of capturing images of the front and back sides of an ID document. Doing so “eliminate[s] the necessity of having insight into the acceptance/rejection criteria” (Jain, col. 1, line 59-62) and improves the speed and efficiency of the verification process (Jain, col. 4, line 47-49).
Claim 23:
Regarding claim 23, Baubert, Martin and Jain teach the elements of claim 19 as stated.
However, Baubert and Martin do not teach the limitations of claim 23.
However, Jain teaches wherein the software functionality processes at least one image captured by at least one end-user's cellphone during the session, {Jain [Col. 3, line 21-45] “Capturing, by a mobile computing device, one or more images of an object. Analyzing, by a pre-validation system in communication with the mobile computing device, one or more quality features of the one or more images. Determining, utilizing a trained neural network and based on the one or more quality features, whether at least a first image of the one or more captured images is usable by a remote post-validation process.”} The mobile device captures an ID card image and analyzes its quality.
and for at least one image so captured, detects that the image is of unsatisfactory quality and, responsively, sends to the user's cellphone, via said software functionality, within the session, a suggestion how to remedy the unsatisfactory quality of the image. {Jain [Col. 5 line 18-41 ] “The image 118 may be analyzed by a pre-validation process to provide feedback as to whether the imperfection would not be acceptable so that the user could capture a new image of the back of the ID card 116… If the imperfection is determined to be likely problematic for the validation service or a post-validation service, one or more features of the captured image may be analyzed by the pre-validation process to provide feedback for the user for correcting the imperfection.” [Col. 11 line 59-66] “If the pre-validation web server 401 determines that captured and uploaded ID image is unacceptable (e.g., bad), one or more of the above-referenced tasks may be performed to provide feedback 408 to the user for suggested corrective action, such as re-positioning the camera of the mobile computing device 102 relative to the ID card.”} Also see col. 5, line 42-59 in Jain. A pre-validation process analyzes an ID card image, detects quality issues that could prevent acceptance by a third party validation service, and provides real-time feedback to a user for corrections.
Jain is analogous art because each of Baubert, Martin and Jain pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert and Martin to include Jain’s teaching of the limitations of claim 23, listed above. Doing so “eliminate[s] the necessity of having insight into the acceptance/rejection criteria” (Jain, col. 1, line 59-62) and improves the speed and efficiency of the verification process (Jain, col. 4, line 47-49).
Claim 24:
Regarding claim 24, Baubert, Martin and Jain teach the elements of claim 19 as stated.
However, Baubert and Martin do not teach the limitations of claim 24.
However, Jain teaches wherein the software functionality processes at least one image captured by at least one end-user's cellphone during the session, {Jain [Col. 5 line 18-41] “The image 118 may be analyzed by a pre-validation process to provide feedback as to whether the imperfection would not be acceptable so that the user could capture a new image of the back of the ID card 116…. If the imperfection is determined to be likely problematic for the validation service or a post-validation service, one or more features of the captured image may be analyzed by the pre-validation process to provide feedback for the user for correcting the imperfection.”} The mobile device captures an ID card image and analyzes its quality.
and for at least one image so captured, detects that the image is of unsatisfactory quality and, {Jain [Col. 5, line 42-59] “A number of imperfections and/or image quality issues may prevent an ID image from be accepted by the validation service, including but not limited to: blur, framing, rotation, keystone, sharpness, brightness, contrast,… Certain example implementations… may be utilized to detect such imperfections before the ID image is uploaded to the validation service, and to provide feedback so that a user take appropriate corrective action.”} Jain’ system analyzes a captured ID card image, detects quality issues that could prevent acceptance by a third party validation service, and provides real-time feedback to a user for corrections.
responsively, provides a binary indicator whose "unsatisfactory" value indicates to the end-user that the image is of unsatisfactory quality. {Jain [Col. 16, line 33-65] “The mobile computing device may be utilized to capture the image, upload the image to the pre-validation server, and receive/display any useful feedback (including an indication of acceptability or rejection of the image), while the bulk of the image analysis may be done by the remote pre-validation web server.”} A mobile device receives and displays feedback including an indication of acceptability or rejection of the ID card image. In this regard, acceptability or rejection is a binary indicator, where “rejection” indicates an unsatisfactory value. This rejection indicator indicates to a user that the ID card image’s image quality is unsatisfactory.
Jain is analogous art because each of Baubert, Martin and Jain pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert and Martin to include Jain’s teaching of the limitations of claim 24, listed above. Doing so “eliminate[s] the necessity of having insight into the acceptance/rejection criteria” (Jain, col. 1, line 59-62) and improves the speed and efficiency of the verification process (Jain, col. 4, line 47-49).
Claim 28:
Regarding claim 28, Baubert, Martin and Jain teach the elements of claim 19 as stated.
Baubert further teaches wherein the link is sent to the end- user's mobile phone via SMS. {Baubert [Col. 7, line 7-19] “The data collection application 108 generates a URL with a GUID for the document.” [Col. 7, line 20-23] “The data collection application 108 sends the URL to the mobile computer device 110 associated with the account or user using the stored contact information. The URL can be sent via SMS or MMS messaging.”}
Claim 29:
Regarding claim 29, Baubert, Martin and Jain teach the elements of claim 19 as stated.
However, Baubert does not teach wherein the software functionality comprises an application.
However, Martin teaches wherein the software functionality comprises an application. {Martin [0024] “FIG. 1, the user 105 may use the mobile device 120 to execute an application or visit a website that requests an image of the user's identification card 115.”} Additionally, Jain also teaches claim 29 (see col. 12, line 5-12).
Martin is analogous art because each of Baubert, Martin and Jain pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert and Jain to include Martin’s teaching of an application. Doing so would enable “perform[ing] document authentication only on images of documents that are of sufficient quality”(Martin, para. 0014), and “decrease computing resources needed for document authentication” (Martin, para. 0014).
Claim 31:
Regarding claim 31, Baubert, Martin and Jain teach the elements of claim 19 as stated.
Baubert further teaches wherein the software functionality comprises Web Desktop software. {Baubert [Col. 4, line 27-45] “Web server computer 106 comprises a data collection application 108 that communicates with the particular application to the computer device 102. The particular application may be a dedicated software application installed on the computer device 102… or may be an online application or website accessible via the browser application 104 executed by the computer device 102.” [Col. 4, line 46-58] “The data collection application 108 determines to request an image of a document 122 from the computer device 102 or the application hosted or used there. The data collection application 108 prompts the computer device 102 for the image by generating and providing an HTML document or causing a local screen display with a prompt.”} As disclosed in Baubert (see Col. 3, line 42-45), computer device 102 is a desktop computer and has a browser application 104. Therefore, online applications or websites that are accessible via the browser application 104 is a web desktop software.
Claim 32:
Regarding claim 32, Baubert, Martin and Jain teach the elements of claim 19 as stated.
Baubert further teaches wherein the software functionality comprises Web Mobile software. {Baubert [Col.7, line 42-58] “In an operation 208, the messaging application 112 invokes the browser 114 on the mobile computer device 110. The browser may display a webpage associated with the URL. In an optional operation 210, the browser 114 receives a further instruction from the mobile computer device to capture an image of a document. For example, FIG. 5A and FIG. 5B depict examples of graphical user interfaces 500 and 550 accessible via a browser 114 for capturing an image. The graphical user interfaces 500 and 550 are displayed on the mobile computer device 110. The graphical user interface 500 is displayed within the browser 114 of the mobile computer device 110 when the URL in the message 404 is selected. In a second portion 504 of the graphical user interface 500, optional text directs the user to select button 506 to capture an image of the indicated document.”} Baubert’s link (i.e., a URL) directs a user to a browser of a mobile computer device when the URL is selected. The browser displays a webpage, where the user can select a button to capture an image of a document without installing any special software on the mobile device. Therefore, Baubert’s URL direct users to a software functionality that comprises web mobile software.
Claim 35:
Regarding claim 35, the claim is directed to a non-transitory tangible computer readable medium containing computer readable program code that can be executed to implement the method recited by claim 19. Therefore, the rejection applied to claim 19 also applies to claim 35. Claim 19 is rejected under the same rationale as claim 35.
Claim 35 further recites a computer program product, comprising a non-transitory tangible computer readable medium having computer readable program code embodied therein, said computer readable program code adapted to be executed to implement the method recited by claim 19. {Baubert [Col. 10, line 41-51] “Computer system 900 also includes a main memory 906, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 902 for storing information and instructions to be executed by processor 904. Such instructions, when stored in non-transitory storage media accessible to processor 904, render computer system 900 into a special-purpose machine that is customized to perform the operations specified in the instructions.”} Also see col. 11, line 9-17 in Baubert.
Claim 36:
Regarding claim 36, the claim is directed to a system that carries out the method recited by claim 19. Therefore, the rejection applied to claim 19 also applies to claim 36. Claim 19 is rejected under the same rationale as claim 36.
Claim 36 further recites a system comprising at least one hardware processor configured to carry out the method recited by claim 19. {Baubert [Col. 10 line 33-40, Fig. 9] “Computer system 900 includes a bus 902 for communicating information, and a hardware processor 904 coupled with bus 902 for processing information. Hardware processor 904 may be, for example, a general purpose microprocessor.”}
Claim 37:
Regarding claim 37, Baubert, Martin and Jain teach the elements of claim 19 as stated.
However, Baubert and Martin do not teach the limitations of claim 37.
However, Jain teaches wherein the software functionality processes at least one image captured by at least one end-user's cellphone during the session in real time. {Jain [Col. 3, line 21-45] “Capturing, by a mobile computing device, one or more images of an object. Analyzing, by a pre-validation system..., one or more quality features of the one or more images. Determining, utilizing a trained neural network and based on the one or more quality features, whether at least a first image of the one or more captured images is usable by a remote post-validation process. Responsive to the determining that the at least a first image is usable,… transmitting, by the mobile computing device, the first image to a remote server for post-validation of the object.”} The mobile device captures an ID card image, analyzes its quality, and uploads acceptable images to a third-party validation service.
Jain is analogous art because each of Baubert, Martin and Jain pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert and Martin to include Jain’s teaching of a software functionality that processes an image captured by an end-user's cellphone during a session in real time. Doing so “eliminate[s] the necessity of having insight into the acceptance/rejection criteria” (Jain, col. 1, line 59-62) and improves the speed and efficiency of the verification process (Jain, col. 4, line 47-49).
17. Claims 20 and 25-27 are rejected under 35 U.S.C. 103 as being unpatentable over Baubert, Martin and Jain as applied to claim 19, and further in view of Tussy et al. (US 2020/0042685 A1), hereafter Tussy.
Regarding claim 20, Baubert, Martin and Jain teach the elements of claim 19 as stated.
However, Baubert, Martin and Jain do not teach wherein said data comprises a selfie, imaged by the end-user's mobile phone's camera, of the end-user's face.
However, Tussy teaches wherein said data comprises a selfie, imaged by the end-user's mobile phone's camera, of the end-user's face. {Tussy [Para. 0074] “A user 108 may have a mobile device 112 that can capture a picture of the user 108, such as an image of the user's face. The user may use a camera 114 on or connected to the mobile device 112 to capture an image or multiple images or video of himself or herself.”}
Tussy is an analogous art because each of Baubert, Martin, Jain and Tussy pertains to processing images captured using a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert, Martin and Jain to include Tussy’ teaching of taking a selfie. Doing so would “provide enhanced security for authenticating a user who has a mobile device” (Tussy, Para. 0142).
Claim 25:
Regarding claim 25, Baubert, Martin and Jain teach the elements of claim 19 as stated.
However, Baubert and Martin do not teach the limitations of claim 25.
However, Jain wherein the software functionality processes at least one image captured by at least one end-user's cellphone during the session, {Jain [Col. 5 line 18-41] “ The digital image 118 may be captured by the user's mobile computing device 102 with off-center framing and/or from too far away. The image 118 may be analyzed by a pre-validation process to provide feedback as to whether the imperfection would not be acceptable so that the user could capture a new image of the back of the ID card 116.”} The mobile device captures an ID card image and analyzes its quality.
and for at least one image so captured, detects that the image is of satisfactory quality and, {Jain [Col. 3, line 21-45] “Capturing, by a mobile computing device, one or more images of an object. Analyzing, by a pre-validation system…, one or more quality features of the one or more images. Determining, utilizing a trained neural network and based on the one or more quality features, whether at least a first image of the one or more captured images is usable by a remote post-validation process. Responsive to the determining that the at least a first image is usable,… transmitting, by the mobile computing device, the first image to a remote server for post-validation of the object.”} When the pre-validation system determines that an ID card image does not have any quality issues that would prevent acceptance by a third party validation service, the mobile device uploads the images to the validation service.
responsively, provides a binary indicator whose "satisfactory" value indicates to the end-user that the image is of satisfactory quality, {Jain [Col. 16, line 33-65] “The mobile computing device may be utilized to capture the image, upload the image to the pre-validation server, and receive/display any useful feedback (including an indication of acceptability or rejection of the image), while the bulk of the image analysis may be done by the remote pre-validation web server.”} The mobile device receives and displays feedback including an indication of acceptability or rejection of the ID card image. In this regard, acceptability or rejection is a binary indicator, where “acceptability” indicates a satisfactory value. This acceptability indicator indicates to a user that the ID card image’s image quality is satisfactory.
Jain is analogous art because each of Baubert, Martin and Jain pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert and Martin to include Jain’s teaching of the limitations of claim 25, listed above. Doing so “eliminate[s] the necessity of having insight into the acceptance/rejection criteria” (Jain, col. 1, line 59-62) and improves the speed and efficiency of the verification process (Jain, col. 4, line 47-49).
However, Jain also does not teach thereby to encourage the end-user to confirm or upload the image to the software functionality.
However, Tussy teaches thereby to encourage the end-user to confirm or upload the image to the software functionality. {Tussy [Para. 0355] “FIG. 31 illustrates an exemplary photo ID image capture screen display. In this exemplary screen layout for the photo ID capture screen 3104 is an ID framing area 3120 in which a photo ID 3112 is framed. A capture photo button 3116 is also provided to activate the mobile computing device to capture the image of the user's ID when the ID is properly framed.” [Para. 0356] “FIG. 32 illustrates an exemplary photo ID image acceptance screen. On this exemplary screen, a retake button 3208 is provided in case the photo is not focused or not aligned properly. An accept button 3212 is provided to allow the user to accept the image of the photo ID displayed in area 3120.”} Accept button 3212 allows the user to accept a photo ID image displayed in area 3120 if the photo is focused or aligned properly. Therefore, the accept button is analogous to an confirm button. The button allows the user to confirm that the photo of his or her ID document is focused and aligned properly. Thus, the accept button encourages the end-user to confirm the photo so it can be uploaded to a facial recognition authentication system (i.e., ID App).
Tussy is analogous art because each of Baubert, Martin, Jain and Tussy pertains to processing images captured using a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert, Martin and Jain to include Tussy’ teaching of encouraging an end-user to confirm or upload the image to a software functionality. Doing so would “provide enhanced security for authenticating a user who has a mobile device” (Tussy, Para. 0142).
Claim 26:
Regarding claim 26, Baubert, Martin and Jain teach the elements of claim 19 as stated.
However, Baubert, Martin and Jain do not teach wherein the software functionality sends to the end-user's mobile phone an image of a rectangular outline, during the session, within which an image of the end-user's face is to be positioned.
However, Tussy teaches wherein the software functionality sends to the end-user's mobile phone an image of a rectangular outline, during the session, within which an image of the end-user's face is to be positioned. {Tussy [Para. 0355] “FIG. 31 illustrates an exemplary photo ID image capture screen display. In this exemplary screen layout for the photo ID capture screen 3104 is an ID framing area 3120 in which a photo ID 3112 is framed. An instruction area 3108 is provided for guidance to the user. A capture photo button 3116 is also provided to activate the mobile computing device to capture the image of the user's ID when the ID is properly framed.” [Para. 0365] “For example, the app software executing on the user's mobile computing device may capture images of the user and user's photo identification, and also upload the image files to the verification server.”} The ID framing area 3120 is a rectangular outline.
Tussy is analogous art because each of Baubert, Martin, Jain and Tussy pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert, Martin and Jain to include Tussy’s teaching of a software functionality that sends to the end-user's mobile phone an image of a rectangular outline, during the session, within which an image of the end-user's face is to be positioned. Doing so would “provide enhanced security for authenticating a user who has a mobile device” (Tussy, Para. 0142).
Claim 27:
Regarding claim 27, Tussy teaches the elements of claim 26 as outlined above.
Baubert further teaches wherein the software functionality captures an image uploaded by the user, {Baubert [Col. 8 line 52 – Col. 9 line 1] “FIG. 7A and FIG. 7B depict examples of graphical user interfaces 700 and 750 accessible on a browser 114 for uploading an image. The mobile computer device 110 provides user interface 700 upon receiving a selection of a stored image in the camera application 116. The interface 700 is displayed in the browser 114 and includes a rendering of the image 652 and an upload button 702. The upload button 702, when selected by the user, instructs the browser 114 to upload the image 652 to the data collection application 108. When the image 652 is successfully uploaded, the browser 114 displays user interface 750 that includes a confirmation 752 that the image 652 was uploaded. In an operation 216, the browser 114 sends the image and the associated GUID to the data collection application 108.”} Image 652 corresponds to the image uploaded by the user.
However, Baubert and Martin do not teach determines, for at least one image so captured, whether a face is presented in the image, and if so, sends a warning to the end-user's mobile phone, during the session, if the end-user's face is not positioned within the rectangular outline.
However, Jain teaches determines, for at least one image so captured, whether a face is presented in the image, and if so, {Jain [Col. 13, line 29-38] “Method 900 includes obtaining captured image(s) of an ID card. In block 904, the method 900 includes analyzing quality feature(s) of the image(s) to determine whether a first image is usable for post-validation using a trained neural network.” [Col. 13, line 56-59] “Outputting, to a display of the mobile computing device, feedback information related to the one or more analyzed quality features.” [Col. 13, line 60-65] “The one or more quality features can include one or more of: fill ratio, blur, framing, rotation, keystone, sharpness, brightness, contrast, color, presence of an image of a human face...”} Also see para. col. 5 line 42-59.
Jain is analogous art because each of Baubert and Jain pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert and Martin to include Jain’s teaching of determining whether a face is presented in images. Doing so “eliminate[s] the necessity of having insight into the acceptance/rejection criteria” (Jain, col. 1, line 59-62) and improves the speed and efficiency of the verification process (Jain, col. 4, line 47-49).
However, Jain also does not teach sends a warning to the end-user's mobile phone, during the session, if the end-user's face is not positioned within the rectangular outline.
However, Tussy teaches sends a warning to the end-user's mobile phone, during the session, if the end-user's face is not positioned within the rectangular outline. {Tussy [Para. 0202] “As shown in FIG. 13A, once enrollment or authentication is begun as described previously, the system causes the user's mobile device 1310 to display a small oval 1320 on the screen 1315 while the mobile device 1310 is imaging the user. Instructions 1325 displayed on the screen 1315 instruct the user to hold the mobile device 1310 so that his or her face or head appears within in the oval 1320.” [Para. 0203] “Next, as shown in FIG. 13B, the system causes the user's mobile device 1310 to display a larger oval 1330 on the display 1315. The display 1315 may also show corresponding instructions 1335 directing the user to “zoom in” on his or her face to fill the oval 1330 with his or her face.” [Para. 0212] “Shapes or guides other than ovals 1320 and 1330 may be used to guide the user to hold the mobile device 1310 at the appropriate distance from his or her face. For example, the mobile device 1310 may show a full or partial square or rectangle frame.”} Ovals 1320 and 1330 maybe be rectangle frame (see Para. 0212). Additionally, Tussy also teaches determining whether a face is presented in a captured image. See para. 0117 and 0168.
Tussy is analogous art because each of Baubert, Martin, Jain and Tussy pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert, Martin and Jain to include Tussy’ teaching of sending a warning to an end-user's mobile phone, during the session, if an end-user's face is not positioned within a rectangular outline. Doing so would “provide enhanced security for authenticating a user who has a mobile device” (Tussy, Para. 142).
18. Claims 30 and 33-34 are rejected under 35 U.S.C. 103 as being unpatentable over Baubert, Martin and Jain as applied to claim 19, and further in view of Larson et al. (US 2020/0366671 A1), hereafter Larson.
Regarding claim 30, Baubert, Martin and Jain teach the elements of claim 19 as stated.
However, Baubert, Martin and Jain do not teach wherein the software functionality comprises a Software Development Kit (SDK).
However, Larson teaches wherein the software functionality comprises a Software Development Kit (SDK). {Larson [Para. 0074] “The IVS (identity verification service) servers 145 may provide interfaces that allow an applicant/enrollee operating client system 105A to capture various forms of biometric data,… submit… identity information, and/or uploaded content to the IVS 140 for identity verification. The interfaces may be developed using website development tools and/or programming languages and/or using platform-specific development tools (for example, Apple® iOS® software development kit (SDK), Nvidia® Compute Unified Device Architecture (CUDA)® Toolkit,).” [Para. 0216] “The program code or data to create the program code may be stored in a state in which they may be read by a computer, but require addition of a library (e.g., a dynamic link library), a SDK, an API, etc. in order to execute the instructions on a particular computing device or other device.”}
Larson is an analogous art because each of Baubert, Martin and Jain and Larson pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert, Martin and Jain to include Larson’s teaching of a software functionality that comprises an SDK. Doing so would “reduce identity theft, fraud, and associated cost” (Larson, para. 0241) and “reduce the friction caused by traditional authentication” (Larson, para. 0241).
Claim 33:
Regarding claim 33, Baubert, Martin and Jain teach the elements of claim 19 as stated.
However, Baubert, Martin and Jain do not explicitly teach wherein the software functionality comprises Native mobile Ios.
However, Larson teaches wherein the software functionality comprises Native mobile Ios. {Larson [Para. 0032] “The client application 110 may be a mobile web browser, a native application (or “mobile app”) specifically tailored to operate on the mobile client system 105.” [Para.0198] “In another example where the system 6400 is a mobile device, the OS may be a mobile OS,… iOS® provided by Apple Inc.®, Windows 10 Mobile® provided by Microsoft Corp.®.”} When the client system 105 is a mobile device and its mobile OS is iOS®, client application 110 runs on Apple mobile devices.
Larson is an analogous art because each of Baubert, Martin and Jain and Larson pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert, Martin and Jain to include Larson’s teaching of a software functionality that comprises Native mobile Ios. Doing so would “reduce identity theft, fraud, and associated cost” (Larson, para. 0241) and “reduce the friction caused by traditional authentication” (Larson, para. 0241).
Claim 34:
Regarding claim 34, Baubert, Martin and Jain teach the elements of claim 19 as stated.
However, Baubert, Martin and Jain do not explicitly teach wherein the software functionality comprises Android software.
However, Larson teaches wherein the software functionality comprises Android software. {Larson [Para. 0032] “The client application 110 may be a mobile web browser, a native application a native application (or “mobile app”) specifically tailored to operate on the mobile client system 105.” [Para.0198] “In another example where the system 6400 is a mobile device, the OS may be a mobile OS, such as Android ® provided by Google Inc.®”} When the client system 105 is a mobile device and its OS is an Android operating system, client application 110 runs on mobile devices that use an Android OS.
Larson is an analogous art because each of Baubert, Martin and Jain and Larson pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert, Martin and Jain to include Larson’s teaching of a software functionality that comprises Android software. Doing so would “reduce identity theft, fraud, and associated cost” (Larson, para. 0241) and “reduce the friction caused by traditional authentication” (Larson, para. 0241).
19. Claim 38 is rejected under 35 U.S.C. 103 as being unpatentable over Baubert, Martin and Jain as applied to claim 19, and further in view of Roach et al. (US 2020/0304650 A1), hereafter Roach, and further in view of Caton et al. (US 2015/0302421 A1), hereafter Caton.
Noted that indicates what the cited art does not teach.
Regarding claim 38, Baubert, Martin and Jain teach the elements of claim 19 as stated.
However, Baubert, Martin and Jain do not teach the limitations of claim 38.
However, Roach teaches wherein said session includes a call to the end-user to place her or his ID in a box or rectangle, which may be presented to the end-user until an ID has been detected; {Roach, para. 0124] “In FIGS. 4A-4H, a user may be provided with a bounding box 404 in the form of a semi-transparent outline of a quadrilateral shape (such as a rectangle) on the display screen 402 of the mobile device to guide the user to make sure the document is fully contained in the display screen during the mobile image capture process. The bounding box may also be accompanied by a written instruction 410 which indicates one or more reasons why the view of the document by the camera is inadequate to capture the image.” [Para. 0125] “The bounding box may also be presented in color combinations which represent how close the user is at achieving optimal image quality. The color of the bounding box 404 may vary dynamically as the user alters the camera or the document so that the document fits within the bounding box. When the document 406 is properly framed within the bounding box 404, the bounding box 404 may turn green to indicate that one or more of the parameters have been satisfied. Other visual or auditory aides may be provided to aid the user in aligning the camera on the mobile device with the document.” [Para. 0126] “FIGS. 4A-4H depict an image capture process for a driver's license.” [Para. 0127] “In FIG. 4H, a correctly proportioned driver’s license 406 is presented, and as a result, a green bounding box 404 is displayed along with an affirmative written instruction 410 telling the user that the parameters have been properly aligned.”} Also see para. 0125 for description of Fig. 4A.
provision of at least one of the following notifications if quality checks are not good: "avoid reflections", "blurred Image", or "too dark"; {Roach [Para. 0127] “FIG. 4E illustrates the automatic capture process where the image is blurry as a result of too much movement of the camera or mobile device. The user may then see the red rectangle 404 along with the written instruction 410 “Hold Steady” which directly instructs the user on how to fix the problem. FIG. 4F is an illustration of a real-time image being displayed on the display screen 402 when there is insufficient light. As a result, the red rectangle 404 is displayed as the bounding box and the written instruction 410 “Not Enough Light” is displayed.”} Also see para. 0127 for description of Fig. 4G.
autocapture of the ID if the ID is detected and all quality checks are good; {Roach [Para. 0068] “Real-time evaluation and enhancement of image quality prior to capturing an image of a document on a mobile device. An image capture process is initiated on a mobile device during which a user of the mobile device prepares to capture the image of the document, utilizing hardware and software on the mobile device to measure and achieve optimal parameters for image capture. Feedback may be provided to a user of the mobile device to instruct the user on how to manually optimize certain parameters relating to image quality, such as the angle, motion and distance of the mobile device from the document. When the optimal parameters for image capture of the document are achieved, at least one image of the document is automatically captured by the mobile device.”} Roach evaluates multiple image quality parameters before capturing the document image. This document may be a driver’s license. A mobile device automatically captures the document image once the parameters fall within acceptable ranges. Therefore, the mobile device performs quality checks on the ID (e.g., a driver’s license) before automatically capturing its image. Claim 38 recites autocapture of the ID occurs if the ID is detected and all quality checks are good, and provision of notifications if quality checks are not good. Given this, the examiner interprets that notifications are provisioned prior to the auto-capturing step.
Roach is analogous art because each of Baubert, Martin, Jain and Roach pertains to processing images captured by a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert, Martin and Jain to include Roach’s teaching of the limitations of claim 38, listed above. Doing so would provide the improvements discussed by Roach in para. 92. For example, para. 0092 discloses that Roach’s method will increase the quality of the captured image, and increase the accuracy of processed information from the image.
However, Roach also does not teaches session termination if the user does not provide an image and/or does not fix image quality until timeout.
However, Caton teaches session termination if the user does not provide an image and/or does not fix image quality until timeout. {Canton [Para. 0182] “FIG. 8C illustrates the reporting of a timeout, which may occur when the hidden/covert security feature 122 cannot be detected by capture application 114. FIG. 8C includes phone status information 802, decoded image 814, results field 816, and input buttons 810 similar to FIG. 8B. However, in FIG. 8C no image data is provided at 814, and the results field 816 provides a message indicating that a timeout occurred.”} As disclosed in para. 0210, Caton’s method may be used to authenticate ID cards via a mobile device. Caton discloses that a timeout condition occurs when the capture application 114 fails to receiving an image for processing.
Caton is analogous art because each of Baubert, Martin, Jain, Roach and Caton pertains to processing images captured using a client device. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baubert, Martin, Jain and Roach to include Caton’s teaching of the limitations of claim 38, listed above. Implementing this combination would enable mobile authentication of important documents such as ID cards (see Caton, para. 0210), and help identify counterfeit documents.
Conclusion
20. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Tamanini et al. (US 2020/0387702 A1 ) discloses authenticating a user’s identification during an interactive communication session. A server determines that the current session step requires ID authentication, generates a URL, encodes the URL in a QR code, and transmits the QR code to a first client device. A second client device then sends a representation of the user’s identification back to the URL, the server determines whether the identification is authentic, and the session proceeds to the next step based on that determination.
21. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BIN QING ZHENG whose telephone number is (703)756-1535. The examiner can normally be reached on M-F 10:00 am - 06:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip J. Chea can be reached on 571-272-3951. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BIN QING ZHENG/
Examiner, Art Unit 2499
/RODMAN ALEXANDER MAHMOUDI/Examiner, Art Unit 2499
Prosecution Insights