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 .
Response to Amendment
2. The Amendment filed March 02, 2026 has been entered. Claims 19, 30, 35, 36 and 38 have been amended. Claim 19-38 are presented for examining. Applicant’s amendments to claim 38 have overcome the claim objections previously set forth in the Non-Final Office Action mailed January 14, 2026. The objection of claim has been withdrawn.
Response to Arguments
3. Applicant’s arguments, see pages 6-9, filed March 02, 2026, with respect to the rejection of claims 19-38 under 35 U.S.C. § 103 have been fully considered but are moot in view of the new grounds of rejection. The claims do not overcome the new ground of rejection made in view of newly found prior art reference(s).
Claim Rejections - 35 USC § 103
4. 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.
5. 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.
6. 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.
7. 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 Jain et al. (US 10,242,283 B1), hereafter Jain, and further in view of Markin et al. (US 2018/0253602 A1), hereafter Markin.
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.
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, {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.”}
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; wherein the software functionality processes at least one image captured by at least one end-user's cellphone during the session, wherein the front-end system sends the at least one image so captured for further processing only when the image is of an ID document, and for at least one image so captured, detects, and communicates to the end-user that the image is of unsatisfactory quality.
However, Jain teaches a software functionality comprising a front-end system, which is operative for end-user identity verification, {Jain [Col. 17, line 8-17] “The mobile computing device may include a mobile app capable of performing part or all of the image pre-validation. The mobile computing device may be utilized to capture the image, perform image analysis using a resident trained neural network, and upload a pre-validated (acceptable) image of the ID card to the third-party ID validation service for ultimate validation. ”} A mobile device captures an ID image (see col. 3, line 21-41), uses a mobile app to analyze quality, and uploads acceptable images to a third-party validation service.
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] “The method may include 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. 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 and analyzes its quality.
and for at least one image so captured, detects, and communicates to the end-user that the image is of unsatisfactory quality. {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 (i.e., the framing offset and/or fill ratio in the case) would not be acceptable so that the user could capture a new image of the back of the ID card 116. The pre-validation service may utilize the trained neural network to determine if the imperfection is acceptable. 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. 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,… 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.” [Col. 12, line 5-12] “One or more of the pre-validation steps 422 may be processed by the mobile computing device 102 using a special purpose native application having a trained neural network 415 , and without requiring upload to the pre-validation web server 401.”} Also see col. 17, line 8-43. A mobile app 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. Analyzing an ID card image to identify quality deficiencies that might impede acceptance by a third-party validator and providing the user with actionable feedback for corrections is analogous to detecting and communicating to an end-user that the image captured is of unsatisfactory quality. This process may be performed by an image processing and analysis app on a mobile device (i.e., a front-end system).
Jain is analogous art because each of Baubert and Jain pertains to processing images captured using a mobile device’s camera. 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 to include Jain’s teaching of the limitations of claim 19, listed above. Doing so “help avoid inefficiencies and actual costs associated with sending an image to a third-party validation platform when the image will likely be rejected due to poor quality, incorrect framing, blur, missing indicia, wrong type of ID, etc” (Jain, col.1 line 49-53).
However, Jain does not teach wherein the front-end system sends the at least one image so captured for further processing only when the image is of an ID document.
However, Markin teaches wherein the front-end system sends the at least one image so captured for further processing only when the image is of an ID document. {Markin [Para. 0066] “The gateway is operative to receive a scanned image and to generate an initial categorization of the scanned image as falling within initial categories such as but not limited to any or all of: form image, ID image, natural image, blank image, other.” [Para. 0041] “A scanned image authentication method employing at least one image authentication station which is unable to process scanned images which do not belong to at least one individual scanned image category, the method comprising: using a gateway image processor for on-line filtering of an incoming scanned image to determine whether or not the incoming scanned image belongs to the scanned image category, and using a computer-implemented interface to transmit each individual scanned image to the at least one image authentication station only if the gateway image processor has determined that the individual scanned image belongs to the at least one individual scanned image category.” [Para. 0146] “Any suitable deployment may be employed to provide functionalities e.g. software functionalities shown and described herein. For example, a server may store certain applications, for download to clients, which are executed at the client side, the server side serving only as a storehouse.”} Markin utilizes a client-side gateway image processor to identify whether an incoming scan is an ID document. The system transmits the image to an authentication station only if it is confirmed to be an ID. The system operates as a streamlined front-end solution.
Markin is analogous art because each of Baubert, Jain and Markin 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 and Jain to include Markin’s teaching of a front-end system that sends images so captured for further processing only when the image is of an ID document. Doing so “filters out input images which are clearly unprocessable by at least one particular station” (Markin, para. 0070) and “reduce total processing time” (Markin, para. 0069).
Claim 21:
Regarding claim 21, Baubert, Jain and Markin 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, Jain teaches wherein said data comprises an image of at least a portion of an ID document borne by the end-user. {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. The ID card 106 may include a photograph 110 of a person.” [Col 4, line 27-29] “The identification card (e.g., ID card) can be a government-issued card such as a passport, driver's license, etc.”}
Jain is analogous art because each of Baubert, Jain and Markin 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 Markin to include Jain’s teaching of capturing a an image of an ID document borne by an end-user. Doing so “help avoid inefficiencies and actual costs associated with sending an image to a third-party validation platform when the image will likely be rejected due to poor quality” (Jain, col.1 line 49-53).
Claim 22:
Regarding claim 22, Jain teaches the elements of claim 21 as outlined above.
However, Baubert and Markin 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, Jain and Markin 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 Markin to include Jain’s teaching of capturing images of the front and back sides of an ID document. Doing so “help avoid inefficiencies and actual costs associated with sending an image to a third-party validation platform when the image will likely be rejected due to poor quality” (Jain, col.1 line 49-53).
Claim 23:
Regarding claim 23, Baubert, Jain and Markin teach the elements of claim 19 as stated.
However, Baubert and Markin 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, Jain and Markin 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 Markin to include Jain’s teaching of the limitations of claim 23, listed above. Doing so “help avoid inefficiencies and actual costs associated with sending an image to a third-party validation platform when the image will likely be rejected due to poor quality” (Jain, col.1 line 49-53).
Claim 24:
Regarding claim 24, Baubert, Jain and Markin teach the elements of claim 19 as stated.
However, Baubert and Markin 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, Jain and Markin 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 Markin to include Jain’s teaching of the limitations of claim 24, listed above. Doing so “help avoid inefficiencies and actual costs associated with sending an image to a third-party validation platform when the image will likely be rejected due to poor quality” (Jain, col.1 line 49-53).
Claim 28:
Regarding claim 28, Baubert, Jain and Markin 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, Jain and Markin teach the elements of claim 19 as stated.
However, Baubert does not explicitly teach wherein the software functionality comprises an application.
However, Jain teaches wherein the software functionality comprises an application. {Jain .” [Col. 12, line 5-12] “In another example variant, one or more of the pre-validation steps 422 may be processed by the mobile computing device 102 using a special purpose native application having a trained neural network 415 , and without requiring upload to the pre-validation web server 401.”} Also see col. 17, line 8-17 in Jain.
Jain is analogous art because each of Baubert, Jain and Markin 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 Markin to include Jain’s teaching of a software functionality that comprises an application. Doing so “help avoid inefficiencies and actual costs associated with sending an image to a third-party validation platform when the image will likely be rejected due to poor quality” (Jain, col.1 line 49-53).
Claim 31:
Regarding claim 31, Baubert, Jain and Markin 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, Jain and Markin 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 computer program product, comprising 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 comprising at least one hardware processor configured to carry 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, Jain and Markin teach the elements of claim 19 as stated.
However, Baubert and Markin do not explicitly teach wherein the software functionality processes at least one image captured by at least one end-user's cellphone during the session in real time.
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, Jain and Markin 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 Markin 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 “help avoid inefficiencies and actual costs associated with sending an image to a third-party validation platform when the image will likely be rejected due to poor quality” (Jain, col.1 line 49-53).
8. Claims 20 and 25-27 are rejected under 35 U.S.C. 103 as being unpatentable over Baubert, Jain and Markin as applied to claim 19, and further in view of Tussy et al. (US 2020/0042685 A1), hereafter Tussy.
Regarding claim 20, Baubert, Jain and Markin teach the elements of claim 19 as stated.
However, Baubert, Jain and Markin 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, Jain, Markin 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, Jain and Markin 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, Jain and Markin teach the elements of claim 19 as stated.
However, Baubert and Markin do not teach the limitations of claim 25.
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 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, Jain and Markin 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 Markin to include Jain’s teaching of the limitations of claim 25, listed above. Doing so “help avoid inefficiencies and actual costs associated with sending an image to a third-party validation platform when the image will likely be rejected due to poor quality” (Jain, col.1 line 49-53).
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, Jain, Markin 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, Jain and Markin 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, Jain and Markin teach the elements of claim 19 as stated.
However, Baubert, Jain and Markin 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, 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, Jain and Markin 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 Markin 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 Markin to include Jain’s teaching of determining whether a face is presented in images. Doing so “help avoid inefficiencies and actual costs associated with sending an image to a third-party validation platform when the image will likely be rejected due to poor quality” (Jain, col.1 line 49-53).
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, Jain and Markin 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, Jain and Markin 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).
9. Claims 30 and 33-34 are rejected under 35 U.S.C. 103 as being unpatentable over Baubert, Jain and Markin as applied to claim 19, and further in view of Larson et al. (US 2020/0366671 A1), hereafter Larson.
Regarding claim 30, Baubert, Jain and Markin teach the elements of claim 19 as stated.
However, Baubert, Jain and Markin 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 the biometric data, 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, Jain, Markin 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, Jain and Markin 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, Jain and Markin teach the elements of claim 19 as stated.
However, Baubert, Jain and Markin 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 platform-specific, such as when the client system 105 is implemented as a mobile device. 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, such as Android ® provided by Google Inc.®, 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, Jain, Markin 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, Jain and Markin 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, Jain and Markin teach the elements of claim 19 as stated.
However, Baubert, Jain and Markin 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 platform-specific, such as when the client system 105 is implemented as a mobile device. 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.®, iOS® provided by Apple Inc.®, Windows 10 Mobile® provided by Microsoft Corp.®.”} 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, Jain, Markin 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, Jain and Markin 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).
10. Claim 38 is rejected under 35 U.S.C. 103 as being unpatentable over Baubert, Jain and Markin 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, Jain and Markin teach the elements of claim 19 as stated.
However, Baubert, Jain and Markin 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, Jain, Markin 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, Jain and Markin to include Roach’s teaching of the elements 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, Jain, Markin, 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, Jain, Markin and Roach to include Caton’s teaching of the elements 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
11. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pribble et al. (US 2020/0387702 A1 ) discloses an application that is designed to automatically capture and transmit a user's identification document. Using the captured image, the application determines the object's real-world size and aspect ratio to identify it as a valid document. Specifically, it compares these metrics to known standards (such as driver's licenses or passports), ensuring that only items with the correct shape and size are recognized. Once confirmed, the application extracts the relevant image and transmits it to a server for further processing. The application is a front-end system that executes locally on a mobile device. See para. 0026 and 0081.
12. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
13. 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
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499