DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on January 12, 2026 has been entered.
Response to Amendment
Applicant canceled claims 1-3, 5, 7, 8, 10-20.
Applicant previously cancelled claims 4, 6, and 9.
Applicant added claims 21-40
Claims 21-40 are pending and have been examined.
Response to Arguments
Applicant's arguments filed January 12, 2026 have been fully considered but they are not persuasive.
Regarding 101 Rejections
Examiner initially rejected claims 1-3, 5, 7, 8, 10-20 under 35 USC 101 as being directed to non-statutory subject matter. Applicant canceled all the claims rendering the rejection moot. Examiner withdraws this rejection.
Regarding Applicant’s preemptive arguments regarding the new claims
Applicant argued that the claims a recite a practical application of the judicial exception. Applicant argued the claims present a technical improvement. Examiner does not find this argument persuasive. Applicant’s claims do not improve technology; the underlying technology remains unaffected by the claims. Applicant is addressing a business problem (operating a parking kiosk) with a business solution. Applicant is merely using existing technology (for its intended purpose) to implement the business solution. Any improvements lie in the abstract idea itself, not in underlying technology. It is not a technical solution to perform system diagnostics on the underlying computer system. The identified limitations do no amount to a practical application because they are a part of the abstract idea. Outside of the abstract idea there remains only the computer implementation of the abstract idea and extra-solution activity. Neither of these are indicative of a practical application. Applicant’s claims do not address a technical limitation/deficiency in the art and thus does not amount to a practical application.
Regarding Prior Art Rejections
Examiner initially rejected claims 1-3, 5, 7, 8, 10-20 as being unpatentable over the prior art. Applicant canceled all the claims rendering the rejection moot. Examiner withdraws this rejection.
Claim Objections
Claim 35 is objected to because of the following informalities: the limitation “the credential verifier is configured the verify…” is grammatically incorrect. The limitation should be “the credential verifier is configured to verify...” Appropriate correction is required.
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 21-40 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 claim(s) contains 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 applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 21, 28, and 35; there is no written support for the limitation “generate, based on the uptime, a transaction validation”. While the specification does teach generating a transaction validation there is no connection between the generation and the uptime.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 21-27 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding claim 21, this claim is indefinite for the following reason:
It is indefinite as to what is meant by the limitation “a time entry to the user device”. It is unclear what “to a user device” is related to. Does it mean a time entry that was entered at a user device? Does Applicant mean that the generated unique credential is sent to a user device?
Regarding claim 22; this claim is indefinite for the following reason:
Claim 21 contains the trademark/trade name “QR code”. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe a multidimensional barcode and, accordingly, the identification/description is indefinite.
Regarding claims 21, 28, and 35, these claims are indefinite for the following reason:
It is indefinite as to what is meant by the limitation “generate, based on the uptime, a transaction validation”. The specification does not teach what is meant by this and there is no logical connection between a computer’s uptime and why a transaction should be validated. For the sake of compact prosecution Examiner will interpret this limitation as generating a transaction validation because the computing device is currently working.
Claims 22-27, 29-34, and 36-40 are rejected due to their dependence on independent claims 21, 28, and 35.
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 21-40 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite the abstract idea which may be summarized as verifying credentials for a transaction.
Step 1 Analysis
Applicants claims are directed to a process (claims 28-34) and machine (claims 21-27, 35-40).
Step 2A, Prong 1 Analysis
Regarding claim 21;
Claim 21 recites the abstract idea/limitations of:
generate a unique credential comprising a unique code and embedded information including a time entry;
receive the unique credential and payment information and synchronize the unique credential to a credential record;
analyze the time entry to monitor an uptime and to generate, based on the uptime, a transaction validation to the credential verifier, and
verify the unique credential against the synchronized credential record and, based on the transaction validation, complete a transaction for time-based access to the secured service area.
As drafted these limitations are a process that falls within the “Certain Methods of Organizing Human Activity grouping of abstract ideas; but for the recitation of generic computer components. If a claim limitation, under its broadest reasonable interpretation, recites performance of the limitation as a commercial/legal interactions, and managing personal behavior or relationships or interactions between people, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. By reciting/claiming a certain method of organizing human activity, Applicant’s claims recite an abstract idea.
Regarding claim 28;
Claim 28 recites the abstract idea/limitations of:
Issuing a unique credential having a unique code and embedded information including a time entry to a user;
synchronizing a credential record corresponding to the unique credential;
analyzing the time entry to monitor an uptime;
generating, based on the uptime, a transaction validation;
receiving the unique credential and payment information from the user;
verifying the unique credential against the synchronized credential record;
and completing the transaction.
As drafted these limitations are a process that falls within the “Certain Methods of Organizing Human Activity grouping of abstract ideas; but for the recitation of generic computer components. If a claim limitation, under its broadest reasonable interpretation, recites performance of the limitation as a commercial/legal interactions, and managing personal behavior or relationships or interactions between people, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. By reciting/claiming a certain method of organizing human activity, Applicant’s claims recite an abstract idea.
Regarding claim 35;
Claim 35 recites the abstract idea/limitations of:
generate a unique credential including a unique code and embedded information including a time entry,
generate a resource allocation to the embedded information based on the unique code,
synchronize a credential record and receive a payment information,
analyze a time entry to monitor kiosk uptime and to generate, based on the uptime, a transaction validation,
verify the unique credential and complete the transaction.
As drafted these limitations are a process that falls within the “Certain Methods of Organizing Human Activity grouping of abstract ideas; but for the recitation of generic computer components. If a claim limitation, under its broadest reasonable interpretation, recites performance of the limitation as a commercial/legal interactions, and managing personal behavior or relationships or interactions between people, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. By reciting/claiming a certain method of organizing human activity, Applicant’s claims recite an abstract idea.
Step 2A, Prong 2 Analysis
This judicial exception is not integrated into a practical application because the claims only recite generic system components for implementing the abstract idea and insignificant extra-solution activity. The claims recite the additional limitations of a user device, a kiosk, a credential issuer, a credential verifier, a kernel monitor, a cloud server, a communications unit, at least one server, a database, and a predictive analytics system; and they are recited at a high level of generality. These system components amount to no more than mere instructions to apply the exception using a generic computer. These limitations generally link the use of the judicial exception to a technological environment and are not indicative of integration into a practical application. The limitations of:
receive the unique credential and payment information and synchronize the unique credential to a credential record;
receiving the unique credential and payment information from the user;
as drafted are insignificant extra-solution activity. These steps are mere data gathering and storing of information and do not qualify as a practical application of the judicial exception. See MPEP 2106.05(g). These additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims as a whole do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea without a practical application.
Step 2B Analysis
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of a user device, a kiosk, a credential issuer, a credential verifier, a kernel monitor, a cloud server, a communications unit, at least one server, a database, and a predictive analytics system; amount to no more than mere components to implement the judicial exception using a generic computer components. For the same reason these elements are not sufficient to provide an inventive concept. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The limitations of:
receive the unique credential and payment information and synchronize the unique credential to a credential record;
receiving the unique credential and payment information from the user;
as drafted are insignificant extra-solution activity. These steps are mere data gathering and storing and do not qualify as significantly more than the judicial exception as they are well-understood, routine, and conventional activity when clamed in a merely generic manner (as it is here). See MPEP 2106.05(g). See Applicant’s specification paragraphs [0039-0043], about implementation of the abstract idea using general purpose or special purpose computing devices; and MPEP 2106.05(f) where applying a computer as a tool is not indicative of significantly more. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Thus Applicant’s claims are not patent eligible.
Dependent Claims Analysis
As for dependent claims 21-24, 27, 29-32, 34, 37 and 38 these claims recite limitations that further define the same abstract idea noted in independent claims 21, 28, and 35. Therefore, claims 21-24, 27, 29-32, 34, 37 and 38 are considered ineligible subject matter for the reasons given above.
As for dependent claims 25, 26, 33, 36, 39, and 40 these claims recite limitations that further define the same abstract idea noted in independent claims 21, 28, and 35. In addition, the recite the additional elements of a back-end operator interface, a kiosk monitoring and self-resolving system, a predictive analytics module. The components are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component. This is not indicative of a practical application or significantly more. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself. Therefore, claims 25, 26, 33, 36, 39, and 40 are considered ineligible subject matter.
Thus, the dependent claims 22-27, 29-34, and 36-40 are not patent-eligible either.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 USC 112(a) or 35 USC 112 first paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of pre-AIA 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on sale in this country, more than one year prior to the date of application for patent in the United States.
Claims 21-25, 27-32, 35, 37, and 38 are rejected under pre-AIA 35 U.S.C. 102(b) as being anticipated by Jain, US Patent Application Publication NO 2022/0351180.
Regarding claim 21;
A self-resolving transaction processing system comprising:
a user device, a kiosk comprising a credential issuer, a credential verifier, and a kernel monitor; a cloud server in communication with the kiosk; and a communications unit coupling the user device, the kiosk, and the cloud server,
See Jain [0036] System 100 may include a facility QR code generator, QR code reader, or combination QR code generator and code reader 165, co-located with each vehicle detection system 150 at each fixed gate location 160 of the parking facility 155.
[0037] System 100 may include a payment gateway 170 accessible over the network 112 by operations of the server application software 125 and platform cloud server 110, client application software 130 and mobile device 135, and/or messaging platform 140. Such an electronic payment system 170 or payment gateway may include, for example, a credit card processing platform, a payments platform, Square, or Paypal, credit card, debit card, Apple Pay, Google Wallet, or any other electronic payment system.
wherein the credential issuer of the kiosk is configured to generate a unique credential comprising a unique code and embedded information including a time entry to the user device;
See Jain [0036] System 100 may include a facility QR code generator, QR code reader, or combination QR code generator and code reader 165, co-located with each vehicle detection system 150 at each fixed gate location 160 of the parking facility 155.
the cloud server is configured to receive the unique credential and payment information from the user device and synchronize the unique credential to a credential record;
See Jain [0051] Once a user mobile device 135 scans the QR code displayed on the QR code generator 165, the default native SMS app 145 may open on the mobile device 135 with a predefined sender number and predefined SMS with an encrypted message. The user's mobile device 135 sends the predefined SMS, and the SMS gateway 140 may send that message to the cloud server 110, and the cloud server may decrypt the SMS message. If the SMS message is validated, and it is verified that the user's vehicle is present at the entry gate 160, the user mobile device 135 may receive the SMS reply from the cloud server 110, with a thank you message and a check-out link generated by the application software 125. On return the user may operate the mobile device 135 to click or select the check-out link received through SMS during check-in.
[0052] In continued reference to the exemplary embodiment in FIGS. 3A and 3B, system 100 may provide a check-out process for the returning user to retrieve the user's vehicle, which may include the following. In an embodiment, the system 100 may be capable of enabling the user to select or click the check-out link, which may direct, or present to, the user to a check-out interface or screen on a user display of the mobile device 135. The check-out screen may display the payment details along with check-in/out details. Once a user operates the mobile device 135 to select or click the proceed to check-out button and payment is done, the user may be redirected to the QR code scanner page or screen. The user may be prompted with a message in case of any error. Once a user scans the QR code through a web page or screen, the cloud server 110 may verify the data and check if the vehicle is present at the exit gate, and may open the exit gate by operation of cloud server 110, and may redirect the user to the thank you page.
the kernel monitor is configured to analyze the time entry to monitor an uptime and to generate, based on the uptime, a transaction validation to the credential verifier, and
See Jain [0052] In continued reference to the exemplary embodiment in FIGS. 3A and 3B, system 100 may provide a check-out process for the returning user to retrieve the user's vehicle, which may include the following. In an embodiment, the system 100 may be capable of enabling the user to select or click the check-out link, which may direct, or present to, the user to a check-out interface or screen on a user display of the mobile device 135. The check-out screen may display the payment details along with check-in/out details. Once a user operates the mobile device 135 to select or click the proceed to check-out button and payment is done, the user may be redirected to the QR code scanner page or screen. The user may be prompted with a message in case of any error. Once a user scans the QR code through a web page or screen, the cloud server 110 may verify the data and check if the vehicle is present at the exit gate, and may open the exit gate by operation of cloud server 110, and may redirect the user to the thank you page.
the credential verifier is configured to verify the unique credential against the synchronized credential record and, based on the transaction validation, complete a transaction for time-based access to the secured service area.
See Jain [0059] In an embodiment, system 100 may be configured to enable check-out by the user operating the mobile device 135 with a QR code displayed by QR code generator 165, instead of a web link. In an embodiment, system 100 may be configured to enable operation of the mobile device 135 at the exit gate 160 to scan the QR code (URL type) displayed on the QR code generator 165 using the QR code scanner enabled camera or other QR code scanner application 147. When the mobile device 135 scans the displayed QR code and selects the embedded link, the default browser of the mobile device 135 may open to a predefined URL and encrypted query string. If validated, the browser at the URL may open a welcome page with input fields such as email and phone number, or otherwise open a check-out screen. If a user operates the mobile device 135 to click or select the submit button on the welcome page, then also the check-out page may open on the display of the mobile device 135. The Check-Out screen may display payment details along with check-in/out details. Once a user clicks the proceed to check-out button and payment is complete, the cloud server 110 may verify the data and check if the user's vehicle is present at the exit gate 160, which may be opened by the operation of the cloud server and server application software 125.
Regarding claim 22;
The system of claim 21, wherein the unique code is a QR code including embedded information that directs the mobile device to a URL for the transaction portal and includes transaction-identifying information comprising at least one of a credential identifier, a credential generation time, and fee rules.
See Jain [0051] Once a user mobile device 135 scans the QR code displayed on the QR code generator 165, the default native SMS app 145 may open on the mobile device 135 with a predefined sender number and predefined SMS with an encrypted message. The user's mobile device 135 sends the predefined SMS, and the SMS gateway 140 may send that message to the cloud server 110, and the cloud server may decrypt the SMS message.
[0083] At the time of setup of these Smart Display Devices in each facility entry and exit lane, unique facility name and specific gate code may be fed into the device through a touchscreen, the built in logic may use these two pieces of information to generate the unique QR code which may also use the timestamp every time to make it a unique QR code. During setup the QR code may be sent to Platform cloud via SMS, this first text may be used to calibrate the cloud with the device.
Regarding claim 23;
The system of claim 21, wherein the unique credential is encrypted to prevent modification or manipulation.
See Jain [0051] Once a user mobile device 135 scans the QR code displayed on the QR code generator 165, the default native SMS app 145 may open on the mobile device 135 with a predefined sender number and predefined SMS with an encrypted message. The user's mobile device 135 sends the predefined SMS, and the SMS gateway 140 may send that message to the cloud server 110, and the cloud server may decrypt the SMS message.
Regarding claim 24;
The system of claim 21, wherein the kiosk comprises a kiosk fee calculator configured to compute fees locally when communication with the cloud server is unavailable,
using embedded information within the unique code to determine at least one of a start time, an end time, and applicable rate logic.
See Jain [0040] In some embodiments, method 700 and system 100 may be capable to calculate the price based on the pricing rules and time of stay and allow the customer to view and pay the electronic ticket any time. The disclosed methods and systems also may be capable to validate at the exit that the customer has fully paid before opening the exit gate.
Regarding claim 25;
The system of claim 21, further comprising a back-end operator interface configured to display a plurality of kiosks on a single screen and provide remote actions including at least barrier control, self-diagnostic testing, system restart, and power cycling.
See Jain [0014] In addition to the customer facing mobile system as described above, a system may include cloud-based administrative functionality as well to enable the administrator to monitor customer usage, open and close gates, take customer payment, and manage and report on customer activities remotely without needing to interact face-to-face with the customer.
[0044] In an embodiment, the system 100 may include fixed posted QR code placards on the gates or a QR code display device that is part of the system and deployed by the facility at the gates.
[0050] FIG. 2 is a simplified block diagram of a computer-implemented system 200 including messaging (SMS) gateway architecture 210 in an exemplary embodiment. System 200 may be identical, in structure and functions, to system 100 disclosed elsewhere herein, except where a person of ordinary skill would otherwise understand or if differences are required by context. FIG. 2 is a simplified block diagram of system 200 including messaging (SMS) gateway 140 architecture. Referring to FIG. 2, in an exemplary embodiment, the customer mobile device 135 may send the predefined SMS with predefined phone number by scanning the QR code 165. SMS may be sent to Messaging Gateway 140 in the base64 encrypted message. Messaging Gateway 140 may call the backend REST API to check the base64 encrypted message, backend decrypt the base64 message, and send the response through REST API. Once Messaging Gateway 140 receives the success response from the backend or server application software 125, messaging gateway 140 sends the SMS reply back to the user's mobile device 135.
Regarding claim 27;
The system of claim 21, wherein completion of the transaction opens an access barrier to permit exit from a secured service area upon verification of the credential record and payment.
See Jain [0052] Once a user scans the QR code through a web page or screen, the cloud server 110 may verify the data and check if the vehicle is present at the exit gate, and may open the exit gate by operation of cloud server 110, and may redirect the user to the thank you page.
Regarding claim 28;
A method for processing time-based access transactions, comprising:
issuing, by a kiosk having a controller kernel monitor, a unique credential having a unique code and embedded information including a time entry to a user;
See Jain [0036] System 100 may include a facility QR code generator, QR code reader, or combination QR code generator and code reader 165, co-located with each vehicle detection system 150 at each fixed gate location 160 of the parking facility 155.
synchronizing, by the kiosk, a credential record corresponding to the unique credential to a cloud server;
See Jain [0051] Once a user mobile device 135 scans the QR code displayed on the QR code generator 165, the default native SMS app 145 may open on the mobile device 135 with a predefined sender number and predefined SMS with an encrypted message. The user's mobile device 135 sends the predefined SMS, and the SMS gateway 140 may send that message to the cloud server 110, and the cloud server may decrypt the SMS message. If the SMS message is validated, and it is verified that the user's vehicle is present at the entry gate 160, the user mobile device 135 may receive the SMS reply from the cloud server 110, with a thank you message and a check-out link generated by the application software 125. On return the user may operate the mobile device 135 to click or select the check-out link received through SMS during check-in.
[0052] In continued reference to the exemplary embodiment in FIGS. 3A and 3B, system 100 may provide a check-out process for the returning user to retrieve the user's vehicle, which may include the following. In an embodiment, the system 100 may be capable of enabling the user to select or click the check-out link, which may direct, or present to, the user to a check-out interface or screen on a user display of the mobile device 135. The check-out screen may display the payment details along with check-in/out details. Once a user operates the mobile device 135 to select or click the proceed to check-out button and payment is done, the user may be redirected to the QR code scanner page or screen. The user may be prompted with a message in case of any error. Once a user scans the QR code through a web page or screen, the cloud server 110 may verify the data and check if the vehicle is present at the exit gate, and may open the exit gate by operation of cloud server 110, and may redirect the user to the thank you page.
analyzing, by the controller kernel monitor, the time entry to monitor an uptime;
See Jain [0040] In some embodiments, method 700 and system 100 may be capable to calculate the price based on the pricing rules and time of stay and allow the customer to view and pay the electronic ticket any time. The disclosed methods and systems also may be capable to validate at the exit that the customer has fully paid before opening the exit gate.
generating, based on the uptime, a transaction validation;
See Jain [0052] In continued reference to the exemplary embodiment in FIGS. 3A and 3B, system 100 may provide a check-out process for the returning user to retrieve the user's vehicle, which may include the following. In an embodiment, the system 100 may be capable of enabling the user to select or click the check-out link, which may direct, or present to, the user to a check-out interface or screen on a user display of the mobile device 135. The check-out screen may display the payment details along with check-in/out details. Once a user operates the mobile device 135 to select or click the proceed to check-out button and payment is done, the user may be redirected to the QR code scanner page or screen. The user may be prompted with a message in case of any error. Once a user scans the QR code through a web page or screen, the cloud server 110 may verify the data and check if the vehicle is present at the exit gate, and may open the exit gate by operation of cloud server 110, and may redirect the user to the thank you page.
receiving the unique credential and payment information from the user;
See Jain [0059] In an embodiment, system 100 may be configured to enable check-out by the user operating the mobile device 135 with a QR code displayed by QR code generator 165, instead of a web link. In an embodiment, system 100 may be configured to enable operation of the mobile device 135 at the exit gate 160 to scan the QR code (URL type) displayed on the QR code generator 165 using the QR code scanner enabled camera or other QR code scanner application 147. When the mobile device 135 scans the displayed QR code and selects the embedded link, the default browser of the mobile device 135 may open to a predefined URL and encrypted query string. If validated, the browser at the URL may open a welcome page with input fields such as email and phone number, or otherwise open a check-out screen. If a user operates the mobile device 135 to click or select the submit button on the welcome page, then also the check-out page may open on the display of the mobile device 135. The Check-Out screen may display payment details along with check-in/out details. Once a user clicks the proceed to check-out button and payment is complete, the cloud server 110 may verify the data and check if the user's vehicle is present at the exit gate 160, which may be opened by the operation of the cloud server and server application software 125.
verifying, at the kiosk, the unique credential against the synchronized credential record;
and completing the transaction.
See Jain [0059] In an embodiment, system 100 may be configured to enable check-out by the user operating the mobile device 135 with a QR code displayed by QR code generator 165, instead of a web link. In an embodiment, system 100 may be configured to enable operation of the mobile device 135 at the exit gate 160 to scan the QR code (URL type) displayed on the QR code generator 165 using the QR code scanner enabled camera or other QR code scanner application 147. When the mobile device 135 scans the displayed QR code and selects the embedded link, the default browser of the mobile device 135 may open to a predefined URL and encrypted query string. If validated, the browser at the URL may open a welcome page with input fields such as email and phone number, or otherwise open a check-out screen. If a user operates the mobile device 135 to click or select the submit button on the welcome page, then also the check-out page may open on the display of the mobile device 135. The Check-Out screen may display payment details along with check-in/out details. Once a user clicks the proceed to check-out button and payment is complete, the cloud server 110 may verify the data and check if the user's vehicle is present at the exit gate 160, which may be opened by the operation of the cloud server and server application software 125.
Regarding claim 29;
The method of claim 28, further comprising encrypting the unique credential to prevent modification, and resolving the embedded information to a specific URL for collection of the service input information and payment information.
See Jain [0051] Once a user mobile device 135 scans the QR code displayed on the QR code generator 165, the default native SMS app 145 may open on the mobile device 135 with a predefined sender number and predefined SMS with an encrypted message. The user's mobile device 135 sends the predefined SMS, and the SMS gateway 140 may send that message to the cloud server 110, and the cloud server may decrypt the SMS message.
[0083] At the time of setup of these Smart Display Devices in each facility entry and exit lane, unique facility name and specific gate code may be fed into the device through a touchscreen, the built in logic may use these two pieces of information to generate the unique QR code which may also use the timestamp every time to make it a unique QR code. During setup the QR code may be sent to Platform cloud via SMS, this first text may be used to calibrate the cloud with the device.
Regarding claim 30;
The method of claim 28, wherein calculating the transaction fee comprises computing a fee based on elapsed time between credential issuance and credential verification, optionally applying flat rates, surge pricing, or alternative payment structures.
See Jain [0040] In some embodiments, method 700 and system 100 may be capable to calculate the price based on the pricing rules and time of stay and allow the customer to view and pay the electronic ticket any time. The disclosed methods and systems also may be capable to validate at the exit that the customer has fully paid before opening the exit gate.
Regarding claim 31;
The method of claim 28, wherein verifying the unique credential comprises determining whether the credential is open or closed based on synchronized information associated with the credential record.
See Jain [0059] In an embodiment, system 100 may be configured to enable check-out by the user operating the mobile device 135 with a QR code displayed by QR code generator 165, instead of a web link. In an embodiment, system 100 may be configured to enable operation of the mobile device 135 at the exit gate 160 to scan the QR code (URL type) displayed on the QR code generator 165 using the QR code scanner enabled camera or other QR code scanner application 147. When the mobile device 135 scans the displayed QR code and selects the embedded link, the default browser of the mobile device 135 may open to a predefined URL and encrypted query string. If validated, the browser at the URL may open a welcome page with input fields such as email and phone number, or otherwise open a check-out screen. If a user operates the mobile device 135 to click or select the submit button on the welcome page, then also the check-out page may open on the display of the mobile device 135. The Check-Out screen may display payment details along with check-in/out details. Once a user clicks the proceed to check-out button and payment is complete, the cloud server 110 may verify the data and check if the user's vehicle is present at the exit gate 160, which may be opened by the operation of the cloud server and server application software 125.
Regarding claim 32;
The method of claim 28, further comprising, upon completion of the transaction, opening an access barrier at the kiosk to permit exit from the secured service area.
See Jain [0052] Once a user scans the QR code through a web page or screen, the cloud server 110 may verify the data and check if the vehicle is present at the exit gate, and may open the exit gate by operation of cloud server 110, and may redirect the user to the thank you page.
Regarding claim 35;
A system configured to perform a method for managing a transaction, the system comprising:
a user device; a kiosk comprising a credential issuer, a credential verifier, a communications unit, and a controller kernel monitor; and a cloud component including at least one server, a database, and a predictive analytics system,
See Jain [0036] System 100 may include a facility QR code generator, QR code reader, or combination QR code generator and code reader 165, co-located with each vehicle detection system 150 at each fixed gate location 160 of the parking facility 155.
[0037] System 100 may include a payment gateway 170 accessible over the network 112 by operations of the server application software 125 and platform cloud server 110, client application software 130 and mobile device 135, and/or messaging platform 140. Such an electronic payment system 170 or payment gateway may include, for example, a credit card processing platform, a payments platform, Square, or Paypal, credit card, debit card, Apple Pay, Google Wallet, or any other electronic payment system.
wherein the credential issuer is configured to generate a unique credential including a unique code and embedded information including a time entry,
See Jain [0036] System 100 may include a facility QR code generator, QR code reader, or combination QR code generator and code reader 165, co-located with each vehicle detection system 150 at each fixed gate location 160 of the parking facility 155.
[0040] In some embodiments, method 700 and system 100 may be capable to calculate the price based on the pricing rules and time of stay and allow the customer to view and pay the electronic ticket any time. The disclosed methods and systems also may be capable to validate at the exit that the customer has fully paid before opening the exit gate.
the cloud component is configured to generate a resource allocation to the embedded information based on the unique code,
See Jain [0036] System 100 may include a facility QR code generator, QR code reader, or combination QR code generator and code reader 165, co-located with each vehicle detection system 150 at each fixed gate location 160 of the parking facility 155.
[0040] In some embodiments, method 700 and system 100 may be capable to calculate the price based on the pricing rules and time of stay and allow the customer to view and pay the electronic ticket any time. The disclosed methods and systems also may be capable to validate at the exit that the customer has fully paid before opening the exit gate.
[0051] Once a user mobile device 135 scans the QR code displayed on the QR code generator 165, the default native SMS app 145 may open on the mobile device 135 with a predefined sender number and predefined SMS with an encrypted message. The user's mobile device 135 sends the predefined SMS, and the SMS gateway 140 may send that message to the cloud server 110, and the cloud server may decrypt the SMS message. If the SMS message is validated, and it is verified that the user's vehicle is present at the entry gate 160, the user mobile device 135 may receive the SMS reply from the cloud server 110, with a thank you message and a check-out link generated by the application software 125. On return the user may operate the mobile device 135 to click or select the check-out link received through SMS during check-in.
[0052] In continued reference to the exemplary embodiment in FIGS. 3A and 3B, system 100 may provide a check-out process for the returning user to retrieve the user's vehicle, which may include the following. In an embodiment, the system 100 may be capable of enabling the user to select or click the check-out link, which may direct, or present to, the user to a check-out interface or screen on a user display of the mobile device 135. The check-out screen may display the payment details along with check-in/out details. Once a user operates the mobile device 135 to select or click the proceed to check-out button and payment is done, the user may be redirected to the QR code scanner page or screen. The user may be prompted with a message in case of any error. Once a user scans the QR code through a web page or screen, the cloud server 110 may verify the data and check if the vehicle is present at the exit gate, and may open the exit gate by operation of cloud server 110, and may redirect the user to the thank you page.
the communications unit is configured to synchronize a credential record with the cloud component and receive a payment information from the user device,
See Jain [0051] Once a user mobile device 135 scans the QR code displayed on the QR code generator 165, the default native SMS app 145 may open on the mobile device 135 with a predefined sender number and predefined SMS with an encrypted message. The user's mobile device 135 sends the predefined SMS, and the SMS gateway 140 may send that message to the cloud server 110, and the cloud server may decrypt the SMS message. If the SMS message is validated, and it is verified that the user's vehicle is present at the entry gate 160, the user mobile device 135 may receive the SMS reply from the cloud server 110, with a thank you message and a check-out link generated by the application software 125. On return the user may operate the mobile device 135 to click or select the check-out link received through SMS during check-in.
[0052] In continued reference to the exemplary embodiment in FIGS. 3A and 3B, system 100 may provide a check-out process for the returning user to retrieve the user's vehicle, which may include the following. In an embodiment, the system 100 may be capable of enabling the user to select or click the check-out link, which may direct, or present to, the user to a check-out interface or screen on a user display of the mobile device 135. The check-out screen may display the payment details along with check-in/out details. Once a user operates the mobile device 135 to select or click the proceed to check-out button and payment is done, the user may be redirected to the QR code scanner page or screen. The user may be prompted with a message in case of any error. Once a user scans the QR code through a web page or screen, the cloud server 110 may verify the data and check if the vehicle is present at the exit gate, and may open the exit gate by operation of cloud server 110, and may redirect the user to the thank you page.
the kernel monitor is configured to analyze a time entry to monitor kiosk uptime and to generate, based on the uptime, a transaction validation,
See Jain [0040] In some embodiments, method 700 and system 100 may be capable to calculate the price based on the pricing rules and time of stay and allow the customer to view and pay the electronic ticket any time. The disclosed methods and systems also may be capable to validate at the exit that the customer has fully paid before opening the exit gate.
[0052] In continued reference to the exemplary embodiment in FIGS. 3A and 3B, system 100 may provide a check-out process for the returning user to retrieve the user's vehicle, which may include the following. In an embodiment, the system 100 may be capable of enabling the user to select or click the check-out link, which may direct, or present to, the user to a check-out interface or screen on a user display of the mobile device 135. The check-out screen may display the payment details along with check-in/out details. Once a user operates the mobile device 135 to select or click the proceed to check-out button and payment is done, the user may be redirected to the QR code scanner page or screen. The user may be prompted with a message in case of any error. Once a user scans the QR code through a web page or screen, the cloud server 110 may verify the data and check if the vehicle is present at the exit gate, and may open the exit gate by operation of cloud server 110, and may redirect the user to the thank you page.
the credential verifier is configured the verify the unique credential and complete the transaction.
See Jain [0059] In an embodiment, system 100 may be configured to enable check-out by the user operating the mobile device 135 with a QR code displayed by QR code generator 165, instead of a web link. In an embodiment, system 100 may be configured to enable operation of the mobile device 135 at the exit gate 160 to scan the QR code (URL type) displayed on the QR code generator 165 using the QR code scanner enabled camera or other QR code scanner application 147. When the mobile device 135 scans the displayed QR code and selects the embedded link, the default browser of the mobile device 135 may open to a predefined URL and encrypted query string. If validated, the browser at the URL may open a welcome page with input fields such as email and phone number, or otherwise open a check-out screen. If a user operates the mobile device 135 to click or select the submit button on the welcome page, then also the check-out page may open on the display of the mobile device 135. The Check-Out screen may display payment details along with check-in/out details. Once a user clicks the proceed to check-out button and payment is complete, the cloud server 110 may verify the data and check if the user's vehicle is present at the exit gate 160, which may be opened by the operation of the cloud server and server application software 125.
Regarding claim 37;
The system of claim 35, wherein the system is configured, upon validating the unique credential at check-in, to allocate resources for a defined duration based on physical space availability, vehicle characteristics, user preferences, reservation features, loyalty benefits, and purchased upgrades, and to provide the allocation to the user via visual display and/or messaging.
See Jain [0059] In an embodiment, system 100 may be configured to enable check-out by the user operating the mobile device 135 with a QR code displayed by QR code generator 165, instead of a web link. In an embodiment, system 100 may be configured to enable operation of the mobile device 135 at the exit gate 160 to scan the QR code (URL type) displayed on the QR code generator 165 using the QR code scanner enabled camera or other QR code scanner application 147. When the mobile device 135 scans the displayed QR code and selects the embedded link, the default browser of the mobile device 135 may open to a predefined URL and encrypted query string. If validated, the browser at the URL may open a welcome page with input fields such as email and phone number, or otherwise open a check-out screen. If a user operates the mobile device 135 to click or select the submit button on the welcome page, then also the check-out page may open on the display of the mobile device 135. The Check-Out screen may display payment details along with check-in/out details. Once a user clicks the proceed to check-out button and payment is complete, the cloud server 110 may verify the data and check if the user's vehicle is present at the exit gate 160, which may be opened by the operation of the cloud server and server application software 125.
Regarding claim 38;
The system of claim 35, wherein the predictive analytics module is further configured to issue a digital credential to a mobile device upon prediction of likely selections, execute pre-check-in resource allocation, and update resource allocation counts following check- in.
See Jain [0051] Once a user mobile device 135 scans the QR code displayed on the QR code generator 165, the default native SMS app 145 may open on the mobile device 135 with a predefined sender number and predefined SMS with an encrypted message. The user's mobile device 135 sends the predefined SMS, and the SMS gateway 140 may send that message to the cloud server 110, and the cloud server may decrypt the SMS message. If the SMS message is validated, and it is verified that the user's vehicle is present at the entry gate 160, the user mobile device 135 may receive the SMS reply from the cloud server 110, with a thank you message and a check-out link generated by the application software 125. On return the user may operate the mobile device 135 to click or select the check-out link received through SMS during check-in.
[0052] In continued reference to the exemplary embodiment in FIGS. 3A and 3B, system 100 may provide a check-out process for the returning user to retrieve the user's vehicle, which may include the following. In an embodiment, the system 100 may be capable of enabling the user to select or click the check-out link, which may direct, or present to, the user to a check-out interface or screen on a user display of the mobile device 135. The check-out screen may display the payment details along with check-in/out details. Once a user operates the mobile device 135 to select or click the proceed to check-out button and payment is done, the user may be redirected to the QR code scanner page or screen. The user may be prompted with a message in case of any error. Once a user scans the QR code through a web page or screen, the cloud server 110 may verify the data and check if the vehicle is present at the exit gate, and may open the exit gate by operation of cloud server 110, and may redirect the user to the thank you page.
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 pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived 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 pre-AIA 35 U.S.C. 103(a) 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.
Claims 26, 33, 34, 39, and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Jain as applied to claims 21-25, 27-32, 35, 37, and 38 above, and further in view of Saito, US Patent Application Publication NO 2005/0129035 .
Regarding claim 26;
Jain does not teach the claim.
Saito teaches:
The system of claim 21, further comprising a kiosk monitoring and self-resolving system configured to automatically detect non-operational device, software, or kernel states at the kiosk, initiate corresponding restarts, perform kiosk power cycling from a backup controller with power timing logic, and issue alerts upon failure to restore operation.
See Saito [0005] In an effort to standardize the physical interfaces and reduce the cost of out-of-band access, server and telecommunication hardware manufacturers started to install service processors into hardware platforms such as stand-alone server motherboards, telecommunications chassis, and blade computers. Service processors, sometimes also called Baseboard Management Cards (BMCs) can take the form of a small processor embedded into the system motherboard of a stand-alone server, an add-on daughter card, or a more sophisticated management module installed in a large system such as a blade computer or telecommunication system chassis. The service processor is designed to remain active and accessible even when modules of the host equipment lock up or otherwise become disconnected from the data network due to a configuration error, hardware or software failure. Service processors may support functionality such as remote power cycling, remote diagnostics, sensor reading, system reset, system console and KVM access.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the computer/kiosk of the primary reference, the ability to perform diagnostics as taught by Saito since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes performing diagnostics on a computer allows for the computer to function properly.
Regarding claim 33;
Jain does not teach the claim.
Saito teaches:
The method of claim 28, further comprising providing a back-end operator interface that simultaneously displays status screens for a plurality of kiosks, enables remote operations including barrier control, diagnostics, restart, and power cycling, and presents individual kiosk operational data.
See Saito [0005] In an effort to standardize the physical interfaces and reduce the cost of out-of-band access, server and telecommunication hardware manufacturers started to install service processors into hardware platforms such as stand-alone server motherboards, telecommunications chassis, and blade computers. Service processors, sometimes also called Baseboard Management Cards (BMCs) can take the form of a small processor embedded into the system motherboard of a stand-alone server, an add-on daughter card, or a more sophisticated management module installed in a large system such as a blade computer or telecommunication system chassis. The service processor is designed to remain active and accessible even when modules of the host equipment lock up or otherwise become disconnected from the data network due to a configuration error, hardware or software failure. Service processors may support functionality such as remote power cycling, remote diagnostics, sensor reading, system reset, system console and KVM access.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the computer/kiosk of the primary reference, the ability to perform diagnostics as taught by Saito since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes performing diagnostics on a computer allows for the computer to function properly.
See Saito [0005] In an effort to standardize the physical interfaces and reduce the cost of out-of-band access, server and telecommunication hardware manufacturers started to install service processors into hardware platforms such as stand-alone server motherboards, telecommunications chassis, and blade computers. Service processors, sometimes also called Baseboard Management Cards (BMCs) can take the form of a small processor embedded into the system motherboard of a stand-alone server, an add-on daughter card, or a more sophisticated management module installed in a large system such as a blade computer or telecommunication system chassis. The service processor is designed to remain active and accessible even when modules of the host equipment lock up or otherwise become disconnected from the data network due to a configuration error, hardware or software failure. Service processors may support functionality such as remote power cycling, remote diagnostics, sensor reading, system reset, system console and KVM access.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the computer/kiosk of the primary reference, the ability to perform diagnostics as taught by Saito since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes performing diagnostics on a computer allows for the computer to function properly.
Regarding claim 34;
Jain does not teach the claim.
Saito teaches:
The method of claim 28, further comprising automatically monitoring kiosk operation and self-resolving failures by restarting device drivers, restarting software, restarting a controller kernel, power cycling the kiosk from a backup controller with power sequencing, and issuing alerts upon persistent failures.
See Saito [0005] In an effort to standardize the physical interfaces and reduce the cost of out-of-band access, server and telecommunication hardware manufacturers started to install service processors into hardware platforms such as stand-alone server motherboards, telecommunications chassis, and blade computers. Service processors, sometimes also called Baseboard Management Cards (BMCs) can take the form of a small processor embedded into the system motherboard of a stand-alone server, an add-on daughter card, or a more sophisticated management module installed in a large system such as a blade computer or telecommunication system chassis. The service processor is designed to remain active and accessible even when modules of the host equipment lock up or otherwise become disconnected from the data network due to a configuration error, hardware or software failure. Service processors may support functionality such as remote power cycling, remote diagnostics, sensor reading, system reset, system console and KVM access.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the computer/kiosk of the primary reference, the ability to perform diagnostics as taught by Saito since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes performing diagnostics on a computer allows for the computer to function properly.
Regarding claim 39;
Jain does not teach the claim.
Saito teaches:
The system of claim 35, wherein the system is configured to operate a back-end operator interface that presents multiple kiosk status screens concurrently and enables remote actions including barrier control, diagnostics, restart, and power cycling.
See Saito [0005] In an effort to standardize the physical interfaces and reduce the cost of out-of-band access, server and telecommunication hardware manufacturers started to install service processors into hardware platforms such as stand-alone server motherboards, telecommunications chassis, and blade computers. Service processors, sometimes also called Baseboard Management Cards (BMCs) can take the form of a small processor embedded into the system motherboard of a stand-alone server, an add-on daughter card, or a more sophisticated management module installed in a large system such as a blade computer or telecommunication system chassis. The service processor is designed to remain active and accessible even when modules of the host equipment lock up or otherwise become disconnected from the data network due to a configuration error, hardware or software failure. Service processors may support functionality such as remote power cycling, remote diagnostics, sensor reading, system reset, system console and KVM access.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the computer/kiosk of the primary reference, the ability to perform diagnostics as taught by Saito since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes performing diagnostics on a computer allows for the computer to function properly.
Regarding claim 40;
Jain does not teach the claim.
Saito teaches:
The system of claim 35, wherein the system further comprises a kiosk monitoring and self-resolving controller configured to monitor device, software, and kernel states, perform
automated restarts, perform kiosk power cycling from a backup controller with power timing logic, execute scheduled restarts and power cycling, synchronize data from the cloud to the kiosk, and issue alerts when operational states are not restored.
See Saito [0005] In an effort to standardize the physical interfaces and reduce the cost of out-of-band access, server and telecommunication hardware manufacturers started to install service processors into hardware platforms such as stand-alone server motherboards, telecommunications chassis, and blade computers. Service processors, sometimes also called Baseboard Management Cards (BMCs) can take the form of a small processor embedded into the system motherboard of a stand-alone server, an add-on daughter card, or a more sophisticated management module installed in a large system such as a blade computer or telecommunication system chassis. The service processor is designed to remain active and accessible even when modules of the host equipment lock up or otherwise become disconnected from the data network due to a configuration error, hardware or software failure. Service processors may support functionality such as remote power cycling, remote diagnostics, sensor reading, system reset, system console and KVM access.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the computer/kiosk of the primary reference, the ability to perform diagnostics as taught by Saito since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes performing diagnostics on a computer allows for the computer to function properly.
Claim 36 is rejected under 35 U.S.C. 103 as being unpatentable over Jain as applied to claims 21-25, 27-32, 35, 37, and 38 above, and further in view of Warner, US Patent Application Publication NO 2005/0280555 .
Regarding claim 36;
Jain does not teach the claim.
Warner teaches:
The system of claim 35, wherein the system further comprises a predictive analytics module configured to prioritize and recommend resource allocations based on at least one of past user behavior, distance and direction traveled, destination, time of rest, preferred features, current location, time, date, weather, maximum daily drive time, current drive time, available resources, percent availability, frequency of availability, and corporate booking policies.
See Warner[0060] Parking matching and routing logic includes algorithms (e.g., parking availability algorithms) to identify optimal parking spaces for users in real time. In addition, the logic provides optimized instructions to guide users to selected parking spaces based upon numerous different parameters including traffic conditions, minimizing time and/or distance, user preferences, user characteristics such as vehicle type, etc. A parking-availability algorithm according to some embodiments of the present invention may combine multiple factors such as the inventory of parking spaces in each lot, parking reservations made within the system of the present invention and the specific nature of the user's reservation request to arrive at an optimal location for parking and/or to predict future availability of a parking space.
[0072] 7. The system of the present invention may use hundreds of data points in a decision process before telling the user the options available over the phone. As indicated above, this decision process may driven by a parking-availability algorithm which may combine multiple factors such as the inventory of parking spaces in each lot, parking reservations made within the system and the specific nature of the user's reservation request to arrive at an optimal location for parking and/or to predict future availability of a parking space.
[0134] 4. Parking-availability Algorithm module--This module may combine multiple factors such as the inventory of parking spaces in each lot, parking reservations made within the system of the present invention and the specific nature of the user's reservation request to suggest an optimal location for parking and/or predict future availability of parking spaces.
[0166] These parking transceivers may be packaged for installation on the road surface of each parking space much like current road "buttons", known as bots-dots. One or more local IP network bridges or parking Internet gateways, nicknamed "snappers", maintain wireless communication with a group of parking transceivers and links with database servers of the system of present invention via the Internet or other communications medium. As described above, the system maintains one or more databases of available parking assets and utilizes a resource allocation engine to allocate parking to service members. This allocation engine may be driven by a parking-availability algorithm that, as indicated above, may combine multiple factors such as the inventory of parking spaces in each lot, parking reservations made within the system of the present invention, and the specific nature of the user's reservation request to suggest an optimal location for parking and/or predict future availability of parking spaces.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the parking lot management of the primary reference, the ability to predict user behavior as taught by Warner since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes predicting availability increases user satisfaction.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J WARDEN whose telephone number is (571)272-9602. The examiner can normally be reached M-F; 9-6 CDT.
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, Bennett M Sigmond can be reached at 303-297-4411. 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.
/MICHAEL J. WARDEN/
Examiner
Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights