Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of AIA .
Status of Claims
This communication is a Final Office action in response to communications received on 02/06/2026. Claims 1, 2, 5, 6, 8, 10, 11, 12, 15, 16, 18 and 20 have been amended. Therefore, claims 1-20 are currently pending and have been addressed below.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Newly amended Independent claims 1 and 11 recite: “for which validation is reusable for multiple job applications”. Applicants’ specification does not include “validation is reusable” and “multiple job applications”, let alone “for which validation is reusable for multiple job applications”.
Further, newly amended Independent claim 1 recites: “automatically generating, by the background check data co-op platform, an electronic application package that includes at least part of the digital work wallet and the validation record, and sending the electronic application package”. Applicant’s specification does not include “electronic application package”, let alone: “automatically generating, by the background check data co-op platform, an electronic application package that includes at least part of the digital work wallet and the validation record, and sending the electronic application package”.
Even further, newly amended Independent claim 1 recites: “in response to a subsequent request to submit an application for a different job by the jobseeker, sending the validation record from the static-qualification portion of the digital work wallet to a different employer system without requesting additional validation data for the qualification from the VTTP computing system.” Applicant’s specification does not include “in response to a subsequent request” and “a different employer system without requesting additional validation data”, let alone: “in response to a subsequent request to submit an application for a different job by the jobseeker, sending the validation record from the static-qualification portion of the digital work wallet to a different employer system without requesting additional validation data for the qualification from the VTTP computing system”.
Further, newly amended Independent claim 11 recites: “based on receipt of a request to submit an application for a different job by the job seeker, send the validation record from the static qualification portion of the digital work wallet to a different employer system without requesting additional validation data for the qualification from the VTTP computing system with the indication that the qualification is validated to an employer system associated with the job; and in response to a subsequent request to submit an application for a different job by the job seeker, send the validation record from the static qualification portion of the digital work wallet to a different employer system without requesting additional validation data for the qualification from the VTTP computing system.” is not in Applicant’s specification.
The ‘written description’ requirement implements the principle that a patent must describe the technology that is sought to be patented; the requirement serves both to satisfy the inventor’s obligation to disclose the technologic knowledge upon which the patent is based, and to demonstrate that the patentee was in possession of the invention that is claimed." Capon v. Eshhar, 418 F.3d 1349, 1357, 76 USPQ2d 1078, 1084 (Fed. Cir. 2005). Further, the written description requirement promotes the progress of the useful arts by ensuring that patentees adequately describe their inventions in their patent specifications in exchange for the right to exclude others from practicing the invention for the duration of the patent’s term.
To satisfy the written description requirement, a patent specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. See, e.g., Moba, B.V. v. Diamond Automation, Inc., 325 F.3d 1306, 1319, 66 USPQ2d 1429, 1438 (Fed. Cir. 2003); Vas-Cath, Inc. v. Mahurkar, 935 F.2d at 1563, 19 USPQ2d at 1116. However, a showing of possession alone does not cure the lack of a written description. Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 969-70, 63 USPQ2d 1609, 1617 (Fed. Cir. 2002). An applicant shows possession of the claimed invention by describing the claimed invention with all of its limitations using such descriptive means as words, structures, figures, diagrams, and formulas that fully set forth the claimed invention. Lockwood v. Amer. Airlines, Inc., 107 F.3d 1565, 1572, 41 USPQ2d 1961, 1966 (Fed. Cir. 1997). The claimed invention as a whole may not be adequately described if the claims require an essential or critical feature which is not adequately described in the specification and which is not conventional in the art or known to one of ordinary skill in the art (MPEP 2163 | (A)). Dependent claims inherit the deficiencies of the parent claims and thus dependent claims are rejected on the same basis as indicated above for the respective parent claims.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception without a practical application and significantly more.
Step 1: Identifying Statutory Categories
When considering subject matter eligibility under 35 U.S.C. § 101, it must be determined whether the claims are directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter (i.e., Step 1). In the instant case, claims 1-10 are directed to a method (i.e. a process). Claims 11-20 are directed to a system (i.e. a machine). Thus, each of these claims fall within one of the four statutory categories. Nevertheless, the claims fall within the judicial exception of an abstract idea.
Step 2A: Prong One: Abstract Ideas
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea. Independent claim 1 recites: a background check data maintains a plurality for respective job seekers, including a static-qualification portion and a non-static-qualification portion, the method comprising: for a particular job seeker, receiving validation data associated with a qualification included of a job seeker; determining that the qualification is a static qualification for which validation is reusable for multiple job applications; based on the determination that the qualification is a static qualification, storing, in the static-qualification portion and based on the validation data, a validation record including an indication that the qualification is validated; based on receipt of a request to submit an application for a job by the job seeker, generating an application package that includes at least part of the validation record, and sending the application package with the indication that the qualification is validated to an employer associated with the job; and in response to a subsequent request to submit an application for a different job by the jobseeker, sending the validation record from the static-qualification portion to a different employer system without requesting additional validation data for the qualification.
Independent claim 11 recites: A system comprising: respective job seekers, a static qualification portion and a non-static qualification portion, for a particular job seeker, receive the validation data associated with the qualification included of the job seeker; determine, based on data describing the qualification, that the qualification is a static qualification for which validation is reusable for multiple job applications; based on the determination that the qualification is a static qualification, store, in the static qualification portion based on the validation data, an indication that the qualification is validated; and based on receipt of a request to submit an application for a different job by the job seeker, send the validation record from the static qualification portion to a different employer system without requesting additional validation data for the qualification with the indication that the qualification is validated to an employer associated with the job; and in response to a subsequent request to submit an application for a different job by the job seeker, send the validation record from the static qualification portion to a different employer without requesting additional validation data for the qualification.
The limitations as drafted, is a process that, under its broadest reasonable interpretation, falls under the abstract groupings of: Certain methods of organizing human activity (commercial or legal interactions (including advertising, marketing or sales activities or behaviors; business relations; (managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). As the claims discuss receiving validation data associated with a qualification of a job seeker; determining, based on the qualification, that the qualification is a static qualification and sending the validated qualification to an employer system associated with the job, which is a clear business relations and one of certain methods of organizing human activity.
Mental Processes (concepts performed in the human mind (including an observation, evaluation, judgement, opinion (claim 1, similar to claim 11 recites for example, “receiving validation data associated with a qualification of a job seeker”; “determining, based on the qualification, that the qualification is a static qualification”; “based on the determination that the qualification is a static qualification, storing the validation data”, “based on receipt of a request to submit an application for a job by the job seeker, sending the indication that the qualification is validated to an employer system associated with the job”.) Concepts performed in the human mind as mental processes because the steps of receiving, determining, verifying, sending and analyzing information mimic human thought processes of observation, evaluation, judgement and opinion, perhaps with paper and pencil, where data interpretation is perceptible in the human mind. See In re TLI Commc’ns LLCPatentLitig., 823 F.3d 607, 611 (Fed. Cir. 2016); FairWarning IP, LLC v. Iatric Sys., Inc., 839 F.3d 1089, 1093-94 (Fed. Cir. 2016)). Further, dependent claims add additional limitations, for example: (claims 2 and 12) based on a determination that the qualification is a non-static qualification, storing the validation data in the non-static portion of with an expiration date; (claims 3 and 13) wherein the qualification includes a drug test, a criminal history report, a background check report, a renewable certification or membership, or any combination thereof; (claims 4 and 14) wherein the qualification includes employment history, residential history, educational history, an assessment or skills test, a professional certification, or any combination thereof; (claims 5 and 15) wherein the indication included in the validation record includes a badge positioned next to the qualification; (claims 6 and 16) based on receipt of permission from the user, storing the validation data; (claims 7 and 17) wherein the validation data includes a report that validates the qualification; (claims 8 and 18) based on a request from the job seeker, removing the indication from the validation record; (claims 9 and 19) based on a request from the employer system associated with the job, sending a request for second validation data for a second qualification of the job seeker; (claims 10 and 20) based on receipt of the second validation data and based on a determination that the second qualification is a static qualification, storing in the static qualification portion the second validation data, a second indication that the second qualification is validated, but these only serve to further limit the abstract idea. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation of methods of organizing human activity and mental processes, but for the recitation of generic computer components, the claims recite an abstract idea.
Step 2A: Prong Two
This judicial exception is not integrated into a practical application because the claims merely describe how to generally “apply” the abstract idea. In particular, the claims only recite the additional elements – computer; background check data co-op platform (BCDCP); server; data store; digital work wallet(s); verified trusted third party (VTTP) computing system; network interface. These additional elements are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components. Simply implementing the abstract idea on generic computer components is not a practical application of the abstract idea, as it adds the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f). The limitations generally link the abstract idea to a particular technological environment or field of use (such as computing, see MPEP 2106.05(h)). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide generic computer implementation and do not impose a meaningful limit to integrate the abstract idea into a practical application.
Step 2B:
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to discussion of integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply an exception and generally link the abstract idea to a particular technological environment or field of use. Furthermore, claims 1-20 have been fully analyzed to determine whether there are additional elements recited that amount to significantly more than the abstract idea. The limitations fail to include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of the abstract idea to a particular technological environment. Thus, nothing in the claim adds significantly more to the abstract idea. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation. The claims are ineligible. Therefore, since there are no limitations in the claim that transform the exception into a patent eligible application such that the claim amounts to significantly more than the exception itself, the claims are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
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 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.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 non-obviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mercury et al. (US 2019/0087781 A1), hereinafter “Mercury”, over O’Malley (US 2019/0392355), hereinafter “O’Malley”.
Regarding Claim 1, Mercury teaches A computer-implemented method executed by a background check data co-op platform comprising at least one server computer and a data store that maintains a plurality of digital work wallets for respective job seekers, each digital work wallet including a static-qualification portion and a non-static-qualification portion, the method comprising: for a particular job seeker, receiving, from a verified, trusted third party (VTTP) computing system, via a network interface of the background check data co-op platform, validation data associated with a qualification included in the digital work wallet of a job seeker; (Mercury, para 0240; para 0218, para 0081, teaches external data aggregators may include third-party data sources accessible to the content management network... Illustrative external data aggregators may include, for example, social networking web servers, public records data stores, learning management systems, educational institution servers, business servers, consumer sales data stores, medical record data stores, etc.; Mercury, Abstract teaches a digital credential repository for employees to identify a plurality of digital credentials; Mercury throughout teaches digital badge portfolio, see at least para 0173 (Examiner interprets as digital work wallets));
determining, by the background check data co-op platform and based on wallet data describing the qualification, that the qualification is a static qualification for which validation is reusable for multiple job applications; (See at least Mercury, Figure 13 and para 0016, teaches determine digital credential expiration and/or recertification times; para 0134, teaches details may include the date on which a badge was issued to a user, and for certain badges, an expiration date associated with the badge; Mercury, para 0240, badge platform server may retrieve the badge portfolio and/or any other available user data (e.g., current employment data, educational qualifications (Examiner notes are static per Applicant’s spec, para 0073, high school diploma), location data, other skills/abilities data, etc.) for the user that initiated the request ...number of jobs/positions being advertised by employers (Examiner notes multiple jobs). Examiner notes nowhere in the reference is it indicated that the method is intended to be limited to a single use. One of ordinary skill in the art would not assume that the invention cannot be used multiple times or used for/by multiple entities);
based on the determination that the qualification is a static qualification, storing, in the static-qualification portion of the digital work wallet in the data store and based on the validation data, a validation record including an indication that the qualification is validated; (Mercury, para 0240, badge platform server may retrieve the badge portfolio and/or any other available user data (e.g., current employment data, educational qualifications (Examiner notes are static per Applicant’s spec, para 0073, high school diploma is static); Storing data is taught throughout Mercury, See at least Mercury Figure 3 and para 0005, para 0095-0099, teaches storing data; Mercury, para 0204, storing of badges and associated badge data, managing badge endorsements, and the like, may be implemented via a centralized badge platform comprising one or more computer servers);
based on receipt of a request to ... for a job by the job seeker, automatically generating, by the background check data co-op platform, an electronic application package that includes at least part of the digital work wallet and the validation record, and sending the electronic application package with the indication that the qualification is validated to an employer system associated with the job; and (Mercury, para 0206, recruiter clients (e.g., creating and importing job data and/or candidate data into the system, associating candidates with job listings or occupations, and vice versa, etc.; Mercury, Figure 33 and para 0207-0210, teaches serving different types of clients (e.g. badge earners, issuers, employers, recruiters, etc.) requesting badge information and permissions; Mercury, para 0218, tailor and group the skills sets of different badge offerings to modify, customize, and market their badges more effectively to employers and individual badge consumers... bundle badges into packages (Examiner interprets as application package. Examiner further notes application package is not in Applicant’s spec));
in response to a subsequent request to ... for a different job by the job seeker, sending the validation record from the static-qualification portion of the digital work wallet to a different employer system without requesting additional validation data for the qualification from the VTTP computing system (Mercury, para 0206, recruiter clients (e.g., creating and importing job data and/or candidate data into the system, associating candidates with job listings or occupations, and vice versa, etc.; Mercury, Figure 33 and para 0207-0210, teaches serving different types of clients (e.g. badge earners, issuers, employers, recruiters, etc.) requesting badge information and permissions; Mercury, para 0240, badge platform server may retrieve the badge portfolio and/or any other available user data (e.g., current employment data, educational qualifications (Examiner notes are static per Applicant’s spec, para 0073, high school diploma), location data, other skills/abilities data, etc.) for the user that initiated the request ...number of jobs/positions being advertised by employers (Examiner notes different jobs)). Yet, Mercury does not appear to explicitly teach and in the same field of endeavor O’Malley teaches submit an application (See at least O’Malley, para 0133, teaches role of the “Applicant” is someone who has completed an application; para 0034, collecting one or more job applications from one or more job applicants for the particular job opening).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Mercury with submit an application as taught by O’Malley with the motivation for the job seekers and the job poster to have a far more efficient system (O’Malley, para 0010). The Mercury invention now incorporating the O’Malley invention, has all the limitations of claim 1.
Regarding Claim 2, Mercury, now incorporating O’Malley, teaches The method of claim 1, further comprising, based on a determination that the qualification is a non-static qualification, storing the validation data in the non-static portion of the digital work wallet with an expiration date (See at least Mercury, Figure 34, teaches an active badge list with expiration date (Examiner notes non-static); Mercury, Figure 13 and para 0016, teaches determine digital credential expiration and/or recertification times).
Regarding Claim 3, Mercury, now incorporating O’Malley, teaches The method of claim 2, wherein the qualification includes a drug test, a criminal history report, a background check report, a renewable certification or membership, or any combination thereof (Mercury, para 0170, Data sources also may include educational record servers (e.g., to obtain the user's grades, transcripts, disciplinary issues), governmental servers (e.g., to obtain the user's criminal record, etc.)).
Regarding Claim 4, Mercury, now incorporating O’Malley, teaches The method of claim 1, wherein the qualification includes employment history, residential history, educational history, an assessment or skills test, a professional certification, or any combination thereof (Mercury, para 0170, Data sources also may include educational record servers (e.g., to obtain the user's grades, transcripts, disciplinary issues; Mercury, para 0222, user data may include demographic data, employment and educational data, other qualifications, current employment details,),
Regarding Claim 5, Mercury, now incorporating O’Malley, teaches The method of claim 1, wherein the indication included in the validation record includes a badge positioned next to the qualification in the digital work wallet (Mercury throughout teaches digital badges, see at least Figure 34 and para 0028, teaches certifying and registering badges within a badging platform, and verifying the associated skills of a badge).
Regarding Claim 6, Mercury, now incorporating O’Malley, teaches The method of claim 1, further comprising, based on receipt of permission from the user, storing the validation data as part of the validation record in the digital work wallet (Mercury, Figure 34 and para 0028, teaches certifying and registering badges and verifying; para 0172, if the user's personality data meets the criteria for one or more personality-related badges (Yes), then in step 2104 the badge issuer may issue the badges to the user and (upon acceptance from the user) transmit the badge data to the platform server for storage in the user's badge portfolio).
Regarding Claim 7, Mercury, now incorporating O’Malley, teaches The method of claim 1, wherein the validation data includes a report that validates the qualification (See at least Mercury, para 0109, teaches generation and management of digital credentials, as well as the reporting of digital credential data).
Regarding Claim 8, Mercury, now incorporating O’Malley, teaches The method of claim 7, further comprising, based on a request from the job seeker, removing the indication from the validation record of the digital work wallet (See at least Mercury, para 0211, While viewing their badge portfolio, the user interface may provide badge earner with buttons/links to add or approve a new badge to the portfolio or remove badges; Mercury, Figure 34 and para 0028, teaches certifying and registering badges and verifying).
Regarding Claim 9, Mercury, now incorporating O’Malley, teaches The method of claim 1, further comprising, based on a request from the employer system associated with the job, sending, to the VTTP, a request for second validation data for a second qualification of the job seeker (Mercury, para 0192, teaches the job may require a second badge; See at least Mercury, Figure 33 and para 0207-0210, teaches serving different types of clients (e.g. employers, recruiters, etc.) requesting badge information).
Regarding Claim 10, Mercury, now incorporating O’Malley, teaches The method of claim 9, further comprising, based on receipt of the second validation data and based on a determination that the second qualification is a static qualification, storing, in the static qualification portion of the digital work wallet based on the second validation data, a second indication that the second qualification is validated (Mercury, para 0192, teaches the job may require a second badge; See at least Mercury, Figure 33 and para 0207-0210, teaches serving different types of clients (e.g. employers, recruiters, etc.) requesting badge information; Storing data is taught throughout Mercury, See at least Mercury Figure 3 and para 0005, para 0095-0099, teaches storing data; Mercury, para 0204, storing of badges and associated badge data; Mercury, para 0240, badge platform server may retrieve the badge portfolio and/or any other available user data (e.g., current employment data, educational qualifications (Examiner notes are static per Applicant’s spec, para 0073, high school diploma), location data, other skills/abilities data, etc.).
Regarding Claim 11, the claim is an obvious variant to claim 1 above, and is therefore rejected on the same premise. Mercury teaches a background check data co-op platform (BCDCP) system configured to: receive the validation data (See at least Mercury, para 0020, FIGS. 17A and 17B are flow diagrams illustrating example processes by which evidence data may be retrieved and/or accessed from a platform server or other data repository.)
Regarding claim 12, the claim recites analogous limitations to claim 2 above, and is therefore rejected on the same premise.
Regarding claim 13, the claim recites analogous limitations to claim 3 above, and is therefore rejected on the same premise.
Regarding claim 14, the claim recites analogous limitations to claim 4 above, and is therefore rejected on the same premise.
Regarding claim 15, the claim recites analogous limitations to claim 5 above, and is therefore rejected on the same premise.
Regarding claim 16, the claim recites analogous limitations to claim 6 above, and is therefore rejected on the same premise.
Regarding claim 17, the claim recites analogous limitations to claim 7 above, and is therefore rejected on the same premise.
Regarding claim 18, the claim recites analogous limitations to claim 8 above, and is therefore rejected on the same premise.
Regarding claim 19, the claim recites analogous limitations to claim 9 above, and is therefore rejected on the same premise.
Regarding claim 20, the claim recites analogous limitations to claim 10 above, and is therefore rejected on the same premise.
Response to Arguments
Applicants arguments filed on 02/06/2026 have been fully considered but they are not persuasive. As an initial matter, Applicant states (remarks page 7), claim 6 was previously canceled. However, claim 6 is not currently canceled; claim 6 is amended.
Regarding 35 U.5.C. § 101 rejections: Examiner has updated the 101 rejection in light of the most recent claim amendments and maintains the 101 rejection. Applicant’s arguments have been fully considered but are found unpersuasive. With respect to the abstract idea, the claimed invention falls within at least the abstract groupings of certain methods of organizing human activity and mental processes as explained in the above 101 analysis. Examiner respectfully notes, Applicant appears to be confusing the additional elements (e.g. computer-implemented data structures, storage partitions, etc.) under Step 2A: Prong One: Abstract Ideas. The additional elements are analyzed in Step 2A: Prong Two and Step 2B of the 101 analysis.
Further, with respect to Applicant’s multiple reliance on McRO, in McRO, the Federal Circuit held the claimed methods of automatic lip synchronization and facial expression animation using computer-implemented rules patent eligible under 35 U.S.C. § 101, because they were not directed to an abstract idea (Step 2A of the USPTO's guidance). The basis for the McRO court's decision was that the claims were directed to an improvement in computer-related technology (allowing computers to produce "accurate and realistic lip synchronization and facial expressions in animated characters" that previously could only be produced by human animators), and thus did not recite a concept similar to previously identified abstract ideas. As part of its analysis, the McRO court examined the specification, which described the claimed invention as improving computer animation through the use of specific rules, rather than human artists, to set morph weights (relating to facial expressions as an animated character speaks) and transition parameters between phonemes (relating to sounds made when speaking). Human artists did not use the claimed rules, and instead relied on subjective determinations to set the morph weights and manipulate the animated face to match pronounced phonemes. The McRO court thus relied on how the claimed rules enabled the automation of specific animation tasks that previously could not be automated when determining that the claims were directed to improvements in computer animation instead of an abstract idea. The McRO court indicated that it was the incorporation of the particular claimed rules in computer animation that "improved [the] existing technological process.” Here, unlike McRO, a computer is merely used as a tool for digital work wallets and background check validation. Therefore, the instant claims are not analogous to McRO.
With respect to Applicant’s remarks (page 12), “The present claims represent an improvement both in computer technology and the life sciences, as expressly identified by the MPEP”. Examiner respectfully notes, it appears Applicant may be confusing this application with another application, as the application is not directed to life sciences. With respect to Applicant’s remarks on integration of the abstract idea into a practical application, the computing elements (computer; background check data co-op platform (BCDCP); server; data store; digital work wallet(s); verified trusted third party (VTTP) computing system; network interface) are additional elements to perform the steps and amount to no more than mere instructions to apply the exception using generic computer components and generally link the abstract idea to a particular technological environment or field of use (such as computing, see MPEP 2106.05(h)). Examiner has reviewed Applicants claims and specification and has found only generic computing elements used in their ordinary capacity. Simply implementing the abstract idea on generic computer components is not a practical application of the abstract idea. Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea; the computer elements merely add the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f). Further, with respect to Applicant’s remarks (page 13), Applicant argues “reducing redundant external calls” and “lowering network load” and “automated generation of application packages”. Examiner respectfully does not find these remarks persuasive as Applicant’s specification does not include these limitations. See above 112 rejection.
Further, with respect to Applicants remarks “static data will remain valid going forward”, Examiner notes this is not a technical solution to a technical problem. Examiner has reviewed Applicant’s claims and specification, and has found broadly claimed computing elements, which do not bring about some benefit to the use of a computing device, nor does it demonstrate a technologically rooted solution to a computer-centric problem or recite an improvement to another technology or technical field. Examiner fails to see how the generic recitations of these most basic computer components and/or of a system so integrates the judicial exception as to “impose a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception.” Guidance, 84 Fed. Reg. at 53. Thus, Examiner finds that the claims recite the judicial exception of certain methods of organizing human activity and mental processes and is not integrated into a practical application.
With respect to Applicant’s remarks on Enfish, in Enfish, the court evaluated the patent eligibility of claims related to a self-referential database. The court concluded the claims were not directed to an abstract idea, but rather an improvement to computer functionality. It was the specification' s discussion of how the invention improved the way the computer stores and retrieves data in memory in combination with the specific data structure recited in the claims that demonstrated eligibility. The claim was not simply using general purpose computers to perform an abstract idea, but a specific implementation of a solution to a problem in the software arts. Unlike Enfish, the instant claimed invention appears to improve upon a judicial exception rather than a problem in the software arts. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. Each step does no more than require a generic
computer to perform generic computer functions. The claims do not, for example, purport to improve the functioning of the computer itself. In addition, the claims do not affect an improvement in any
other technology or technical field. The specification spells out different generic equipment and parameters that might be applied using the concept and the particular steps such conventional processing would entail based on the concept of information access. Thus, the claims at issue amount to nothing significantly more than instructions to apply the abstract idea using some unspecified, generic computer(s). Therefore, Applicants remarks are found unpersuasive and Examiner maintains the 101 rejection with respect to these and all depending claims unless otherwise indicated.
Regarding 35 U.S.C. § 103 rejections. With respect to the prior art rejections, Applicants arguments have been fully considered but are found unpersuasive. Examiner has updated the rejections in light of the most recent claim amendments.
With respect to Applicant’s remarks (page 16): “Applicant respectfully submits that Mercury does not describe determining that a qualification is static in the sense that its validation is reusable across multiple job applications, nor does Mercury describe making such a determination based on wallet data describing the qualification. Therefore, Mercury does not disclose or suggest "determining ... that the qualification is a static qualification for which validation is reusable for multiple job applications," as recited in independent claim 1.”
Examiner respectfully disagrees.
As an initial matter, Applicant’s own specification does not include “validation is reusable for multiple job applications”, see above 112 rejection. Further, nowhere in the references is it indicated that the method/system is intended to be limited to a single use. Nor, do the references, at any point, preclude the method/system from being used for multiple job applications. One of ordinary skill in the art would not assume that the invention intended to be used only once or for one job application. Likewise, one of ordinary skill in the art would not assume that the invention cannot be used multiple times or that it cannot be used for multiple job applications. With respect to Applicant’s remarks (page 17): “Applicant respectfully submits that nothing in Mercury describes a system behavior in which previously obtained validation data is reused for subsequent employer submissions while affirmatively bypassing further validation requests to the validating entity. To the contrary, Mercury's platform continues to contemplate interactions with issuers, certification services, and external data sources to maintain badge validity, adjust expiration dates, or reapply evidence. Thus, while Mercury discloses storing badge data and serving badge portfolios to employers, it does not disclose or suggest the claimed reuse of validation records across multiple job applications without requesting additional validation data from the validating system. Therefore, Mercury does not disclose or suggest "sending the validation record ... without requesting additional validation data for the qualification from the VTTP computing system."
Examiner respectfully disagrees.
As an initial matter, Applicant’s own specification does not include “without requesting additional validation data for the qualification from the VTTP computing system”, see above 112 rejection. Again, with respect to the “claimed reuse of validation records across multiple job applications” arguments, nowhere in the references is it indicated that the method/system is intended to be limited to a single use. Nor, do the references, at any point, preclude the method/system from being used for multiple job applications. One of ordinary skill in the art would not assume that the invention intended to be used only once or for one job application. Likewise, one of ordinary skill in the art would not assume that the invention cannot be used multiple times or that it cannot be used for multiple job applications. In response to applicant’s argument that there is no motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, as both references are in the field of employment, it would be obvious to one of ordinary skill in the art to combine the references for a more efficient system (O’Malley, para 0010).
Therefore, Applicants remarks are found unpersuasive and Examiner has updated maintains the 103 rejections for all claims.
Conclusion
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to REBECCA R NOVAK whose telephone number is (571)272-2524. The examiner can normally be reached Monday - Friday 8:30am - 5:00pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynda Jasmin can be reached on (571) 272-6782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/R.R.N./ Examiner, Art Unit 3629
/ANDREW B WHITAKER/ Primary Examiner, Art Unit 3629
Prosecution Insights