DETAILED ACTION
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 the AIA .
Status of Claims
This Office action is in response to correspondence received September 16, 2025.
Claim 1 is amended, claim 8 is canceled. Claims 1-7 are pending and have been examined.
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-7 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s):
A method of facilitating the offline digital notarization of documents, the method comprising the steps of:
providing at least one notary account, wherein the notary account is associated with a corresponding notary personal computing (PC) device, and wherein the digital journal includes a plurality of journal event logs;
providing at least one signing user account , wherein the signing user account is associated with a digital user signature;
prompting the notary account to input background information ;
prompting the notary account to input signing user identification (ID) information ;
prompting the signing user account to enter the user signature ;
prompting the signing user account to enter biometric user information ;
compiling the signing user information, the signing user ID information, the user signature, and the biometric user information into a new journal event log ;
timestamping the new journal event log ;
(I) appending the new journal event into the journal;
prompting the notary account to validate the new journal event after step (H), if the journal event log is timestamped; validating the new journal event ; generating a validation report ; appending the validation report into the new journal event log ; and performing step (I), if the new journal event is validated
These steps recite a certain method of organizing human activity which is a patent ineligible abstract idea. The steps describe steps for notarizing, which is a legal interaction. Legal interactions under MPEP 2106.04(a) are: “including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations).” The key word is including. Including means is not an exclusive list and the historic, well-known, understood process of notarizing is a known, understood legal practice that identifies the signer of a document. By virtue of being a legal process, it is included. The biometric information may be information relayed such as the data of a fingerprint or the data of an iris and therefore is information. Therefore, the abstract idea, drawn from Applicant’s claims and properly analyzed according to MPEP guidance, is a certain method of organizing human activity.
This judicial exception is not integrated into a practical application. The elements of a notary PC device that includes a digital journal; managing/using a corresponding notary PC device; a document validation module that is used and is provided on the corresponding notary PC device; and digital signature. The digital journal and digital signature are under a broadest reasonable interpretation in light of the specification the analog version in digital form. /Firstname Lastname/ is a digital signature. The digital journal as well, is anything that is written out but on a computer. A notary PC device that is “Managed or used” is synonymous with applying a PC to the abstract idea of doing notary steps. See MPEP 2106.05(f)(1-2). Taken together, these additional elements in combination amount to instructions to perform notarizing steps on a computer, which is not a practical application of an abstract idea.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because for the same reasoning that the combination of elements is not a practical application, the reasoning is carried over here: the combination of elements is not significantly more.
Per the dependent claims:
Claim 2 further describes the abstract idea by combining information from the various additional elements.
Claim 3 recites a biometric scanner which is a further apply it invention as a scanner under a broadest reasonable interpretation could be taught by a smartphone (fingerprint scanner – iPhone; scanning face or other with camera – all smartphone).
Claim 4 further describes the abstract idea and the additional element of reentering biometric information if unsuccessfully captured is an apply it step of repeating something that doesn’t work. There are no technical details of this only that a desired outcome or result is claimed, and this is therefore a further apply it step. See MPEP 2106.05(f)(1).
Claim 5 recites limitations to a device cover. However, under a broadest reasonable interpretation in light of the specification, the device cover would be taught by a magnetic tablet or smartphone cover, which as a generic computing device, is a further apply it step.
Claim six recites removable storage device but this is used in its ordinary capacity to store information and be able to transfer information due to its removability and therefore is an apply it limitation.
Claim seven recites limitations that if all were included in claim 1 would overcome the 101 rejection because the limitations of using the GPS module of one device and the tracking of a second device is a practical application as it is not merely applying the abstract idea to a computer or ordinary machinery but performing steps necessitating two devices in order to protect confidential data, see pages 11-12 of specification. This therefore is a practical application of the abstract idea. Claim 7 is rejected solely because it is based on claim 1.
Therefore claims 1-7 are rejected under 35 USC 101.
Claim Rejections - 35 USC § 103
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 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.
Claim(s) 1-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Giobbi et al., USPGPUB 20070260888 A1 ("Giobbi") in view of Gibson et al., USPGPUB 20200258176 A1 ("Gibson").
Per claim 1, Giobbi teaches a method of facilitating the offline digital notarization of documents, the method comprising the steps of in par 099: “The user PDK 802 is then updated 1410 by storing the information to the memory of the PDK. Information associated with a registry update (user PDK ID, Notary ID, programmer ID, site ID, registry ID, timestamps, etc.) can also be written to the storage module 910 of the Programmer 810 to enable future audits. In an alternative embodiment, the Programmer 810 can operate as a portable standalone device that can register a user PDK 802 in an offline mode. ”
Giobbi then teaches providing at least one notary account, wherein the notary account is associated with a corresponding notary personal computing (PC) device, in par 046: “The profile fields 220 can be initially empty at the time of manufacture but can be written to by authorized individuals (e.g., a Notary) and/or hardware (e.g., a Programmer). In one embodiment, each profile 220 comprises a profile history 222 and profile data 230. Many different types of profiles 220 are possible.” Because the profile is written by authorized individuals including a Notary and a Programmer (for hardware) the profile is under a broadest reasonable interpretation associated with a corresponding notary personal computing device. See also par 053: “The profile history 222 includes a programmer ID field 224, a Notary ID 226, and a site ID field 228. The profile history 222 relates to the specific hardware, Notary, and site used at the time the profile data was created and stored to the PDK.”
wherein the corresponding notary PC device includes a digital journal, and wherein the digital journal includes a plurality of journal event logs in par 091: “In one embodiment, the storage module 910 includes long-term storage for storing programming history information. Programming history can include, for example, the PDK ID, Notary ID, site ID, and timestamps associated with the programming of any PDK. The programming history can be recalled at a later time for auditing purposes.” This teaches wherein the corresponding notary PC device includes a digital journal, and wherein the digital journal includes a plurality of journal event logs.
Giobbi then teaches providing at least one signing user account managed by the corresponding notary PC device, wherein the signing user account is associated with a digital user signature in par 035: “FIG. 1 is a high level block diagram illustrating a system for securely authenticating an individual for transaction-processing and/or access control applications. The system 100 comprises a Personal Digital Key (PDK) 102, a Reader 108, a network 110 and one or more external databases including a validation database 112, a Central Registry 114 and one or more private registries 116.” See also par 037: “The PDK 102 is a compact, portable uniquely identifiable wireless device typically carried by an individual. The PDK 102 stores digital information in a tamper-proof format that uniquely associates the PDK 102 with an individual.” See also par 037: “The PDK 102 is a compact, portable uniquely identifiable wireless device typically carried by an individual. The PDK 102 stores digital information in a tamper-proof format that uniquely associates the PDK 102 with an individual.” See also par 039 : “ The biometric input 104 comprises a representation of physical or behavioral characteristics unique to the individual. For example, the biometric input 104 can include a fingerprint, a palm print, a retinal scan, an iris scan, a photograph, a signature, a voice sample or any other biometric information such as DNA, RNA or their derivatives that can uniquely identify the individual. The Reader 108 compares the biometric input 104 to information received from the PDK 102 to determine if a transaction should be authorized. Alternatively, the biometric input 104 can be obtained by a biometric reader on the PDK 102 and transmitted to the Reader 108 for authentication. In additional alternative embodiment, some or all of the authentication process can be performed by the PDK 102 instead of the Reader 108.” See also pars 051-052.
Giobbi then teaches prompting the notary account to input background information using the corresponding notary PC device in par 038 “The process is ensured by a trusted third-party system, referred to herein as a Notary, that administers the acquisition and storage of information in the PDK 102 according to defined security protocols. In one embodiment, the Notary is a system and/or a trusted individual that witnesses the acquisition and storage either in person or remotely.”: See also pars 051-052 : “"A profile can further include personal identification information such as name, address, phone number, etc., bank information, credit/debit card information, or membership information. This information can be useful for certain types of transactions. For example, with purchases that require delivery, a PDK 102 can automatically transmit address information to the Reader 108 at the point of transaction. In one embodiment, a profile can store multiple addresses. At the point of transaction, the Reader 108 displays the address options and allows the user to select which address to use.
Generally, some types of profile information (e.g., a biometric profile) can only be acquired during a trusted initialization process that is administered by a trusted Notary. In one embodiment, other secure information such as credit card information are also stored to the PDK in the presence of a Notary. Alternatively, certain types of low-risk information can be added by the user without a Notary, such as, for example a change of address.”
Giobbi then teaches prompting the notary account to input signing user identification (ID) information using the corresponding notary PC device in par 036: “The system 100 addresses applications where it is important to ensure a specific individual is authorized to perform a given transaction. A transaction as used herein can include executing a purchase or financial dealing, enabling access to physical and/or digital items, verifying identification or personal information or executing other tasks where it is important to authenticate an individual for use. Generally, the Reader 108 wirelessly receives information stored in the PDK 102 that uniquely identifies the PDK 102 and the individual carrying the PDK 102. The Reader 108 can also receive a biometric input 104 from the individual. Based on the received information, the Reader 108 determines if the transaction should be authorized.”
Giobbi then teaches prompting the signing user account to enter the digital user signature using the corresponding notary PC device in par 039: “In one embodiment, the Reader 108 is adapted to receive a biometric input 104 from the individual. The biometric input 104 comprises a representation of physical or behavioral characteristics unique to the individual. For example, the biometric input 104 can include a fingerprint, a palm print, a retinal scan, an iris scan, a photograph, a signature, a voice sample or any other biometric information such as DNA, RNA or their derivatives that can uniquely identify the individual”
Giobbi then teaches prompting the signing user account to enter biometric user information using the corresponding notary PC device in par 039: “ In one embodiment, the Reader 108 is adapted to receive a biometric input 104 from the individual. The biometric input 104 comprises a representation of physical or behavioral characteristics unique to the individual. For example, the biometric input 104 can include a fingerprint, a palm print, a retinal scan, an iris scan, a photograph, a signature, a voice sample or any other biometric information such as DNA, RNA or their derivatives that can uniquely identify the individual”
Giobbi then teaches compiling the signing user information, the signing user ID information, the digital user signature, and the biometric user information into a new journal event log using the corresponding notary PC device in par 098: “In one embodiment, initialization history information is also written to the Notary PDK 806. Here, a Notary PDK 806 can store a record of every initialization performed by the Notary. This information can be used for auditing purposes in the future. For example, if a Notary's rights are revoked, any initializations performed by that Notary can be recovered from the Notary's PDK 806. Then, user PDKs 802 initialized by that Notary may need to be disabled until re-initialized by the user.”
Giobbi then teaches timestamping the new journal event log using the corresponding notary PC device in par 097: “History data includes information documenting the initialization process such as the Notary ID, the Programmer's ID, and the site ID (indicating the location of the initialization), registration date and time, and so on.”
Giobbi then teaches and appending the new journal event into the digital journal using the corresponding notary PC device in par 098: “In one embodiment, initialization history information is also written to the Notary PDK 806. Here, a Notary PDK 806 can store a record of every initialization performed by the Notary. This information can be used for auditing purposes in the future. For example, if a Notary's rights are revoked, any initializations performed by that Notary can be recovered from the Notary's PDK 806. Then, user PDKs 802 initialized by that Notary may need to be disabled until re-initialized by the user.”
Giobbi does not teach providing the corresponding notary PC device with a document validation module
prompting the notary account to validate the new journal event using the corresponding notary PC device after step (H), if the journal event log is timestamped
validating the new journal event using the document validation module
generating a validation report using the document validation module
appending the validation report into the new journal event log using the corresponding notary PC device
and performing step (I), if the new journal event is validated by the document validation module
Gibson teaches a method for signing an electronic document. See abstract.
Gibson teaches providing the corresponding notary PC device with a document validation module in par 224 : “Compliance Audit Certificate (CAC) unit 2118 may be configured to generate a digital CAC 5000 for each electronic document 3000 that is executed or annotated.”
Gibson then teaches prompting the notary account to validate the new journal event using the corresponding notary PC device after step (H), if the journal event log is timestamped in par 234 : “ For example, block 6200 may include one or more of the following fields: a pointer to a preceding block 6210, user identity information 6220, a timestamp (including date) 6230, the digital signature or annotation 6340, a compliance audit certificate 6350, and a pressure profile 6360 for the signature.” See also par 0236: “Timestamp field 6230 may include data representing the precise date and time at which the a signature or annotation is made within the electronic document 3000.”
Gibson then teaches validating the new journal event using the document validation module in par 234: “FIG. 7 is an example schematic diagram of an example block 6200 in an example blockchain 6000, according to some embodiments. In some embodiments, an electronic document 3000 may be executed or annotated by one or more users or parties. The electronic document 3000 may be for example an agreement representing terms for a transaction acceptable to the parties of the agreement, such as an agreement of sale and purchase of a real estate property. Each user may use a respective client computing device 311 to enter user input required to generate a digital signature. Each time a valid digital signature is generated and incorporated into an electronic document 3000, a new block may be generated and appended to blockchain 6000.”
Gibson then teaches generating a validation report using the document validation module in par 241: “Each document, which may be a smart contract, can include assignment of one or more assets. Assets can also be registered and verified by system 2100 (or via a third party service). For example, a registered asset may be associated with an owner having a digital wallet at a public key address in a blockchain. The registered asset can be transferred as part of the smart contract to another party, once the smart contract has been executed in full.” See also par 0224, see also Fig 5, item 2100, item 2118.
Gibson then teaches appending the validation report into the new journal event log using the corresponding notary PC device in par 242: “Once the smart contract has been fully signed by all parties, and the appropriate payment has been made in cryptocurrency as recorded and witnessed by all nodes on the blockchain 6000, the registered asset may be transferred to a new address (e.g. a new digital wallet) belonging to the assignee, executing the agreement within the smart contract in full.” See also par 0241, 0224.
Gibson then teaches and performing step (I), if the new journal event is validated by the document validation module in par 243: “In some embodiments, the electronic document may contain an additional page(s) or portion, referred to herein as a Compliance Audit Certificate (CAC) 5000. FIG. 8 illustrates an example compliance audit certificate 5000, which may be digitally generated, in accordance with some embodiments. As depicted, the CAC contains entries for each party to a signing session or agreement. For each party, there may be a space for one or more of the party's name, email address, signature, and supporting identification.”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the notary teachings of Giobbi with the validation teachings of Gibson because Gibson teaches that repudiation can happen without these teachings, see par 006. Because attempting to back out of an agreement after the fact is a risk Gibson teaches that these challenges can be alleviates, see pars 008-009. For these reasons one would be motivated to modify Giobbi with Gibson.
Per claim 2, Giobbi and Gibson teach the limitations of claim 1, above. Giobbi further teaches providing the notary account with a notary digital signature managed by the corresponding notary PC device in par 093: ”The step of checking 1104 the PDK standings vary slightly for an Notary PDK 806. Here, the check 1104 ensures that the Notary is a registered Notary, that no fraudulent activity has been associated with the Notary or any PDK initialized or registered by the Notary, that the software internal to the Notary PDK 806 is valid and has not been tampered with, and that the Notary can be trusted to administer the initialization.”
Giobbi then teaches prompting the notary account to enter notary information using the corresponding notary PC device before step (C) in par 095: ”The step of checking 1104 the PDK standings vary slightly for an Notary PDK 806. Here, the check 1104 ensures that the Notary is a registered Notary, that no fraudulent activity has been associated with the Notary or any PDK initialized or registered by the Notary, that the software internal to the Notary PDK 806 is valid and has not been tampered with, and that the Notary can be trusted to administer the initialization.”
Giobbi then teaches and appending the notary information into the notary digital signature using the corresponding notary PC device in par 099: ” Initialization optionally includes acquiring 1006 biometric information to be stored in the biometric profile of the user PDK 802 as illustrating in FIG. 12. To begin the process, the Programmer 802 requests 1202 biometric input 804 from the user. The biometric input 804 is then scanned 1204 by the biometric reader 902.”
Per claim 3, Giobbi and Gibson teach the limitations of claim 1, above. Giobbi further teaches providing the notary account with biometric login data managed by the corresponding notary PC device, and wherein the corresponding notary PC device is provided in a lock status in par 070: “ For example, a particular Reader 108 may be configured to perform only a fingerprint authentication and therefore any PDK without a fingerprint biometric profile cannot be used with the Reader 108.”
Giobbi then teaches providing the corresponding notary PC device with a biometric scanner in par 074: “It is noted that biometric contact is not limited to physical contact and can be, for example, the touch of a finger to a fingerprint scanner, the positioning of a face in front of a facial or retinal scanner, the receipt of a signature, the detection of a voice, the receipt of a DNA sample, RNA sample, or derivatives or any other action that permits the Reader 108 to begin acquiring the biometric input 104. By supplying the biometric contact, the user indicates that the authentication and transaction process should proceed.”
Giobbi then teaches prompting the notary account to enter biometric data using the biometric scanner before step (C) in par 074: “For example, in biometric authentication, the authentication process cannot continue until the Reader detects a biometric contact and receives biometric information. It is noted that biometric contact is not limited to physical contact and can be, for example, the touch of a finger to a fingerprint scanner, the positioning of a face in front of a facial or retinal scanner, the receipt of a signature, the detection of a voice, the receipt of a DNA sample, RNA sample, or derivatives or any other action that permits the Reader 108 to begin acquiring the biometric input 104. By supplying the biometric contact, the user indicates that the authentication and transaction process should proceed. For example, a PDK holder that wants to make a withdrawal from an Automated Teller Machine (ATM) equipped with a Reader 108 initiates the withdrawal by touching a finger to the Reader 108.”
Giobbi then teaches and unlocking the corresponding notary PC device, if the biometric data entered matches the biometric login data in par 074: “For example, a PDK holder that wants to make a withdrawal from an Automated Teller Machine (ATM) equipped with a Reader 108 initiates the withdrawal by touching a finger to the Reader 108. The ATM then begins the transaction process for the withdrawal.” See also pars 070-071.
Per claim 4, Giobbi and Gibson teach the limitations of claim 1, above. Giobbi further teaches providing the corresponding notary PC device with a biometric scanner in par 070: “For example, a particular Reader 108 may be configured to perform only a fingerprint authentication and therefore any PDK without a fingerprint biometric profile cannot be used with the Reader 108.”
Giobbi then teaches prompting the signing user account to enter biometric user information using the biometric scanner during step (F) in par 074: “In a first configuration, a trigger is required to continue the process because of the type of authentication being used. For example, in biometric authentication, the authentication process cannot continue until the Reader detects a biometric contact and receives biometric information. It is noted that biometric contact is not limited to physical contact and can be, for example, the touch of a finger to a fingerprint scanner, the positioning of a face in front of a facial or retinal scanner, the receipt of a signature, the detection of a voice, the receipt of a DNA sample, RNA sample, or derivatives or any other action that permits the Reader 108 to begin acquiring the biometric input 104.”
Giobbi then teaches compiling the biometric user information into the new journal event log using the corresponding notary PC device during step (G), if the biometric user information is successfully captured by the biometric scanner in par 099: “A registry entry can include for example, the unique user PDK, purchasing information (such as credit/debit/ATM card information or bank account information), and personal information (such as name, address, phone number, date of birth, etc.). The user PDK 802 is then updated 1410 by storing the information to the memory of the PDK. Information associated with a registry update (user PDK ID, Notary ID, programmer ID, site ID, registry ID, timestamps, etc.) can also be written to the storage module 910 of the Programmer 810 to enable future audits.”
Giobbi then teaches and prompting the signing user account to reenter the biometric user information, if the biometric user information is unsuccessfully captured by the biometric scanner in par 095: “Programmer 810 checks 1206 the quality of each scan to ensure that the captured biometric input 804 is valid. If 1208 the quality is not satisfactory (due to, for example, improper positioning during the scan), the Programmer 810 repeats the request 1202 for biometric input 804.”
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Giobbi et al., USPGPUB 20070260888 A1 ("Giobbi"), in view of Gibson et al., USPGPUB 20200258176 A1 ("Gibson"), further in view of Mori et al., US PGPUB 20140139989 (“Mori”).
Per claim 5, Giobbi and Gibson teach the limitations of claim 1, above. Giobbi does not teach providing the corresponding notary PC device with a device cover, wherein the device cover is removably attached to a device display of the corresponding notary PC device,
wherein the device display includes at least one cover switch, wherein the device cover is engaged with the cover switch, and wherein the corresponding notary PC device is provided in an inactive status
and unlocking the corresponding notary PC device before step (C), if the device cover does not engage the cover switch.
Mori teaches a case for a tablet. See abstract.
Mori teaches providing the corresponding notary PC device with a device cover, wherein the device cover is removably attached to a device display of the corresponding notary PC device in par 041: “In a number of embodiments, cover frame 410 can be configured to fit within cover perimeter frame 401 and cover sides 402, and can be configured to receive and fittingly secure the tablet computing device. Cover frame 410 can include one or more frame sides 411, which can be configured to hold the back and sides of the tablet computing device. Frame sides 411 can form a frame lip 412, which, in some embodiments, can wrap around sufficiently to fittingly secure the tablet computing device. Frame lip 412 may be positioned around a portion of one or more edges of the front surface of the tablet computing device to secure it, but can in many embodiments leave the screen of the tablet computing device exposed for a user to manipulate.”
Mori then teaches wherein the device display includes at least one cover switch, wherein the device cover is engaged with the cover switch, and wherein the corresponding notary PC device is provided in an inactive status in par 034: “In additional embodiments, front frame piece 253 can include a sleep magnet recess 256, which can be configured to hold and secure a sleep magnet 257. In various embodiments, sleep magnet 257 is configured to interact with a sleep/wake sensor on a tablet computing device held by tablet keyboard case 100 (FIG. 1). Various tablet computing devices, such as the iPad, use the sleep/wake sensor to sense the proximity of sleep magnet 257 and thus detect whether tablet keyboard case 100 is in a closed configuration (as shown in FIG. 9, described below), in which case the tablet computing device can put itself to sleep, including turning off its screen.”
Mori then teaches and unlocking the corresponding notary PC device before step (C), if the device cover does not engage the cover switch in par 058: “For example, FIG. 13 shows tablet cover assembly 120 including various slots configured for an iPad, including a dock connector slot 1310 configured to allow an iPad docking cable to connect to the iPad's dock connector, a speaker slot 1320 configured to allow sound from the iPad speaker to pass through and not be as muffled by tablet cover assembly 120, a button slot 1330 configured to allow a user to manipulate volume buttons on the iPad, a camera slot 1340 configured to allow light to pass through tablet cover assembly 120 to the iPad's back camera, a sleep slot 1350 configured to allow a user to manipulate the iPad's sleep/wake button,”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the mobile device based teachings of Giobbi with the tablet cover teachings of Mori because Mori teaches in par 003: “Protective cases can be used to protect these devices from possible damage. It is desirable that these cases allow continued functionality of various capabilities of the devices while the devices remain held in the cases. Moreover, it is also desirable that these cases enhance the capability, functionality, and/or usability of these devices.”. As this would protect the device used for notary work, one would be motivated by Moris taught motivation to combine Mori with Giobbi. For these reasons, one would be motivated to combine Mori with Giobbi.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Giobbi et al., USPGPUB 20070260888 A1 ("Giobbi"), in view of Gibson et al., USPGPUB 20200258176 A1 ("Gibson"), further in view of Tortosa et al., US PGPUB 20230188986 (“Tortosa”).
Per claim 6, Giobbi and Gibson teach the limitations of claim 1, above. Giobbi further teaches prompting the notary account to select journal event logs from the plurality of journal event logs to be transferred using the corresponding notary PC device after step (I) in par 099: “Information associated with a registry update (user PDK ID, Notary ID, programmer ID, site ID, registry ID, timestamps, etc.) can also be written to the storage module 910 of the Programmer 810 to enable future audits.”
Then Giobbi teaches and transferring the selected journal event logs from the corresponding notary PC device, if the journal event logs from the plurality of journal event logs are selected by the notary account in par 099: “In an alternative embodiment, the Programmer 810 can operate as a portable standalone device that can register a user PDK 802 in an offline mode. Then, the Programmer can be later coupled to a network to upload any new registrations to a private registry 116, Central Registry 114, or validation database 112.”
Giobbi does not teach providing the corresponding notary PC device with at least one removable storage device, wherein the removable storage device is electronically connected to the corresponding notary PC device; removable storage device.
Tortosa teaches a system for collecting information, see par 05.
Tortosa teaches providing the corresponding notary PC device with at least one removable storage device, wherein the removable storage device is electronically connected to the corresponding notary PC device; removable storage device in par 032: “Moreover, the computing system 110-120 comprises a number of controllers for peripherals, or Input/Output (I/O) units, 230; for example, as far as relevant to the present disclosure, the peripherals 230 of each collection/certification server 110,120 comprise a network card for plugging the collection/certification server 110,120 into the corresponding data center and then connecting it to a console of the data center for its control (for example, a personal computer, also provided with a drive for reading/writing removable storage units, such as of USB type) and to a switch/router sub-system of the data center for its communication with the network 105,”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the mobile/offline notary teaching of Giobbi with the removable storage device teaching of Tortosa because Tortosa teaches that the transmitting is able to work for a notary public, see par 056: “However, the certification computing system may be of any type (for example, a server, a virtual machine, a cloud service and so on) and of any certification authority (for example, a laboratory, a government agency, a notary public and so on).” Further teaches that this ensures the accuracy of information collected see par 017. As improving accuracy for a notary public is important this would motivate one ordinarily skilled to combine Tortosa with Giobbi. Therefore for these reasons one would be motivated to combine Giobbi with Tortosa.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Giobbi et al., USPGPUB 20070260888 A1 ("Giobbi"), in view of Gibson et al., USPGPUB 20200258176 A1 ("Gibson"), further in view of Canfield et al., US PGPUB 20170230357 (“Canfield”), further in view of Youtube, how to use Find My to locate lost Apple Devices like the iPhone, published 2021, available at: < https://youtu.be/o2Q2x6lBteo?t=138 > (“Find my”).
Per claim 7, Giobbi and Gibson teach the limitations of claim 1, above. Giobbi further teaches providing the corresponding notary PC device with a global positioning system (GPS) module, and wherein the notary account is further associated with a secondary notary PC device in par 044: “For example, a PDK 102 can be integrated into a portable electronic device such as a cell phone, Personal Digital Assistant (PDA), or GPS unit,”
Giobbi then teaches tracking the geographic location of the corresponding notary PC device in par 097: “History data includes information documenting the initialization process such as the Notary ID, the Programmer's ID, and the site ID (indicating the location of the initialization), registration date and time, and so on.”
Giobbi does not teach tracking the geographic location using the GPS module
prompting the notary account to enter a tracking prompt using the secondary notary PC device
relaying the tracking prompt from the secondary notary PC device to the corresponding notary PC device, if the tracking prompt is entered by the notary account
relaying the current geographic location of the corresponding notary PC device from the corresponding notary PC device to the secondary notary PC device.
Canfield teaches secure transaction techniques. See pars 003-004.
Canfield teaches tracking the geographic location using the GPS module in par 020: “Additionally, using the method of the present invention, security may be enhanced by requiring the location of the mobile device and the second device be approximately in the same geographical location. For example, its IP address and the device might determine a PC location by GPS data.”
Canfield then teaches prompting the notary account to enter a tracking prompt using the secondary notary PC device in par 18: “In yet another preferred embodiment, an authentication server receives a login request by a second device. The login attempt carries information that associates it to a first device previously registered with the authentication server.”
Canfield then teaches relaying the tracking prompt from the secondary notary PC device to the corresponding notary PC device, if the tracking prompt is entered by the notary account in par 19: “In still yet another preferred embodiment, the authentication application and a second device must be within a certain specified proximity in order to send or receive login notifications and requests. In one example, a first device which has been authenticated and for which the current location of the device is known through GPS coordinates can only receive a login confirmation notification from an authentication server if the GPS coordinates are within a certain distance from a specified location of a second device. For example, the first device and the second device may need to be within the same country. In another example of this embodiment, the authentication server may not consider a login request as valid if the first device and second device are not within a specified distance from each other.”
Canfield then teaches relaying the current geographic location of the corresponding notary PC device from the corresponding notary PC device to the secondary notary PC device in par 19: “In still yet another preferred embodiment, the authentication application and a second device must be within a certain specified proximity in order to send or receive login notifications and requests. In one example, a first device which has been authenticated and for which the current location of the device is known through GPS coordinates can only receive a login confirmation notification from an authentication server if the GPS coordinates are within a certain distance from a specified location of a second device.”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the notary on mobile device teaching of Giobbi with the security teachings of Canfield because Canfield teaches in par 006: “Therefore, there is a need for reducing human failure issues with the tap to login procedure, reducing issue with timeouts and use of server resource and making attacks by trying multiple usernames or even knowing a username less likely to result in a data breech. The present invention solves this and many other problems in a unique and novel manner.” A timeout, common in many devices, would prevent the notary work from happening and therefore one would be motivated to modify Giobbi with Canfield to unlock a device that had timed out. For this reason one would be motivated to modify Giobbi with Canfield.
Giobbi does not teach and displaying the current geographic location of the corresponding notary PC device using the secondary notary PC device.
Find My teaches the find my feature on iOS devices.
Find My teaches and displaying the current geographic location of the corresponding notary PC device using the secondary notary PC device at 2:18 where the image shows the location of the PC device using the secondary notary PC device (which has the display screen).
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the mobile notary teaching of Giobbi with the displaying the current geographic location teaching of Find My because one could have useful information using this teaching to specifically locate a notary PC device along with map features to show how to get there. This would enable one to find the person who has the corresponding notary PC device trying to be used. One would be motivated therefore to modify Giobbi with Find My in order to have relevant location information that would assist in finding the person holding the device.
Therefore, claims 1-7 are rejected under 35 USC 103.
Response to Arguments
35 USC 101
Applicant:
Applicant respectfully disagrees with the examiner's position that the claimed invention is directed to an abstract idea without significantly more because the present invention discloses a method for selecting an appointment on remote servers and personal computing devices and is significantly more than methods of organizing human activity.
Response:
Applicant argues that remote servers and PCs are significantly more than the abstract idea. Applicant does not argue against the abstract idea itself. The presence of servers and PCs, even performing steps, is discussed in MPEP 2106.05(f)(2), see TLC Communication, Capital One, Alice. Based on these precedents, the instructions to have computers perform the abstract idea steps is not a practical application or significantly more as the legal interaction steps are only applied to the computers. The substance of Applicant arguments follow.
Additionally, Applicant respectfully disagrees with the Examiner's statement that the claims of the present invention do not include additional elements that are sufficient to amount to significantly more than the judicial exception. An "inventive concept" is furnished by an element or combination of elements that is recited in the claim in addition to the judicial exception, and is sufficient to ensure that the claim as a whole amounts to significantly more than the judicial exception itself. Alice Corp., 573 U.S. at 27-18, 110 USPQ2d at 1981 (citing Mayo, 566 U.S. at 72-73, 101 USPQ2d at 1966). Here, Applicant has not merely introduced a method to perform the Steps of the present invention but incorporates various elements of computing devices, specifically a computer, battery, biometric scanner, an internal storage and predefined inputs for executing the Steps of implementing an notary journal designed to
facilitate the system and method of facilitating the offline digital notarization of documents wherein the computing device and storage device are essential elements and components of the claimed invention.
Applicant argues unclaimed additional elements that exist in the specification but not in the claims. The only additional elements that can be argued are those that were claimed in in the independent claim (Applicant may argue the dependent claims separately).
The combination of elements in claim 1 (as well as the dependent claims) were addressed as they are claimed in an apply it manner, and also their combination is apply it, for example as smartphones (A PC device) have biometric scanners. The additional elements for the independent claim are: a notary PC device that includes a digital journal; managing/using a corresponding notary PC device; a document validation module that is used and is provided on the corresponding notary PC device; and digital signature. These were addressed in combination in the rejection above. Smartphones also have batteries and therefore the combination of a battery and a PC device is a smartphone which is equivalent to a mobile unit, specifically addressed in TLC Communications, MPEP 2106.05(f)(2).
The remote servers are involved in every step of the present invention.
Applicant has not recited how remote servers are in every step of the present invention. Or, if this is the case, it is not explicit in the claims. At any rate, the claims as recited may have a server but the server is recited in an apply it manner, as shown in the rejection above.
The computing device is also a necessary component in order to make the invention function as intended. If you remove the personal computing device, there is no invention left. It is inconceivable to separate the present invention from these two necessary components as doing so would render the entire system unusable. Essentially, without the presence of a personal computing device and the availability of a storage, the method of the present invention would be impossible to implement. The Supreme Court has noted that "it is consistent with the general rule that patent claims 'must be considered as a whole."' Alice Corp., 573 U.S. at 218 n.3, 110 USPQ2d at 1981 (quoting Diamond v. Diehr, 450 U.S. 175, 188, 209 USPQ 1, 8-9 (1981)). Consideration of the elements of the present invention, namely the elements of the social network in conjunction with remote servers and personal computing devices, in combination is particularly important, because even if an additional element does not amount to significantly more on its own, it can still amount to significantly more when considered in combination with the other elements of the claim.
Computer usage is addressed in guidance from Alice et seq. Examiner agrees that computer is “necessary” for the claims and was considered as a whole as all elements were considered however please ref Alice in guidance MPEP 2106.05(f)(2). This is the sum total and correct rejection under the MPEP guidance, long established and based on the case law. Alice’s holding is that a commonplace business method being performed on a computer as not being sufficient to overcome 101, see Id. This considers the claims as a whole as not only the business method (for Alice, settling funds, for this application, a notary) but the computer (and all the other computerized elements) are considered both alone and in combination. Therefore this is unpersuasive.
See, e.g., Rapid Litig. Mgmt. v. CellzDirect, 827 F.3d 1042, 1051, 119 USPQ2d 1370, 1375 (Fed. Cir. 2016) (process reciting combination of individually well-known freezing and thawing Steps was "far from routine and conventional" and thus eligible); BASCOM Global Internet Servs. v. AT&T Mobility LLC, 827 F.3d 1341, 1350, 119 USPQ2d 1236, 1242 (Fed. Cir. 2016) (inventive concept may be found in the non-conventional and non-generic arrangement of components that are individually well-known and conventional). Here, combining the method for a customizable wait list notification for appointments with the vital computational components amounts to an inventive concept and is sufficient to ensure that the claim as a whole amounts to significantly more than the judicial exception itself.
Applicant has shown no evidence that the combination of additional elements is unconventional and in fact Examiner did not find that there was well-understood, routine, and conventional use of additional elements; instead was found that they were “Apply it” elements, see MPEP 2106.05(f)(1-2).
Examiner made a note in claim 7 where the 101 rejection was not maintained and that if each and every element is included into claim 1 then the 101 rejection would be overcome.
35 USC 102
Claim 1 claims the limitation "providing at least one notary account, wherein the notary account is associated with a corresponding notary personal computing (PC) device, wherein the corresponding notary PC device includes a digital journal, and wherein the digital journal includes a plurality of journal event logs." Examiner draws attention to paragraph 91 of Giobbi. Paragraph 91 of Giobbi outlines that a storage module contained long term storage for programming history, which includes notary ID, site ID, timestamps. However, the present invention include a digital journal that include a plurality of event logs. The specification, on page 4, lines 3- page 5, line 1, states "The digital journal includes a plurality of journal event logs corresponding to permanen