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
Due to communications filed 10/20/25, the following is a non-final office action. Claims 1, 8 and 15 are amended. Claims 1-20 are pending in this application and are rejected as follows.
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 10/20/25 has been entered.
Claim Rejections - 35 USC §101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title,
Claims 1-20 are rejected under 35 U.S.C, 101 because the claimed invention is directed toa judicial exception (l.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
With regard to the present claims 1-20, these claim recites a series of steps and, therefore, is a process, and ultimately, is statutory.
In addition, the claim recites a judicial exception. The claims as a whole recite “Certain Methods of Organizing Human Activity”. The claimed invention is a method that allows for access, analysis, update and communication of electronic ride request records, which are concepts for managing personal behavior of relationships or interactions between people (including social activities, teaching, and following rules or instructions). The mere nominal recitation of a generic computer/computer network does not take the claim out of the “Certain Methods of Organizing Human Activity” grouping. Thus, the claim recites an abstract idea.
Furthermore, the claims are not integrated into a practical application. The claim as a whole merely describes how to generally “apply” the concept of accessing, analyzing, updating and communicating ride request information in a computer environment. The claimed computer components are recited at a high level of generality and are merely invoked as tools to perform an existing ride request records update process. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea.
Finally, the claims do not recite an inventive concept. As noted previously, the claim as a whole merely describes how to generally “apply” the concept of accessing, analyzing, updating and communicating information related to ride request records in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e., an inventive concept) to the abstract idea. The claim is ineligible.
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-AlA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AlA) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 5, 6, 8-10, 12, 13, 15, 16, 17, 19, 20, is/are rejected under 35 U.S.C. 103 as being unpatentable over Goldman et al (US 9087320 B2), and further in view of ZOLFAGHARI (CA 3232345 A1), and further in view of Subhiksha, J. G. K., and Soma Prathibh. "Kids Carpooling Mobile Application”, now referred to as Subhiksha et al.
As per claim 1, Goldman et al discloses:
transmitting the ride request to a plurality of authorized drivers from among the ride provider users in the hive, (Goldman: (56) |n some embodiments, the system is able to optimize storage and management of parent/family specific data...Features and applications that are improved by this structure may include:...carpool; (96) Car Pooling (97) The sports management system provides the ability for valid volunteer drivers to form carpools to facilitate the transportation of athletes to and from predetermined athletic events. (99) Some embodiments may use text messaging to notify the carpool driver that an available seat within their vehicle has been selected. Some embodiments may include the name and location of the carpool rider as part of the standard notification message to the carpool driver. Some embodiments may include mapping capabilities that provide a desirable route for pickup and delivery of carpool riders based on rider addresses and event location);
receiving, by the server, an electronic indication of acceptance of the ride request from a particular authorized driver device associated with a particular authorized driver, (Goldman: (19) Embodiments of the system may be implemented in various operating environments that include personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, digital cameras, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, set top boxes, systems on a chip (SOCs), and so on. The computer systems may be cell phones, personal digital assistants, smart phones, personal computers, programmable consumer electronics, digital cameras, and so on; (100) Some embodiments may include the availability of the carpool driver to either accept or reject the rider requesting a ride. For example, when a driver receives a notification that a seat has been occupied, the driver's mobile device will indicate the requested seat by indicating the seat as occupied and applying a stroke to the outside of the rider icon. The driver can then click on the new icon and click on an accept or reject button control to finalize the request. Some embodiments include status notifications to the requesting rider when a ride request is either accepted or rejected); and
updating, by the server, in real-time, ride status information for at least one device associated with a member of the hive, (Goldman: (19) Embodiments of the system may be implemented in various operating environments that include personal computers, server computers, handheld or laptop devices... The computer systems may be cell phones, personal digital assistants, smart phones, personal computers, programmable consumer electronics...(100) Some embodiments include status notifications to the requesting rider when a ride request is either accepted or rejected).
Goldman does not disclose the following limitations, however, ZOLFAGHARI, discloses:
affiliating, by the server each ride provider user in the hive with at least one ride recipient user in the hive, (ZOLFAGHARI, ({0059] At block 280, the software application in the cloud computer 125 establishes a communication channel between the first device and a second device of another user to enable a generation, via the transport arrangement system as an intermediary to the first device and the second device, of shared ride data. The shared ride data may be generated by the cloud computer 125 on the basis of information provided by the first user device (based on input from the first user via the GUI on the first user device) and/or information provided by the second user device (based on input from the second user via the GUI on the second user device);
receiving, from a user of the group of users in the hive, a ride request, wherein the ride request comprises a pickup location, a drop-off location, and a time, (ZOLFAGHARI, [0003] In general, the first example embodiment is directed at a method to facilitate a shared ride request received by a transport arrangement system from a first user device of a first user; [0063] Example operations can include verifying the number of users undertaking the shared ride, a type of vehicle used for the shared ride (a personal vehicle, a ride share vehicle, a taxi, a limousine etc.), a travel status of each user (approved, canceled, pending, etc.), allowing time adjustments (pick up time, drop-off time, etc.),
It would have been obvious to one of ordinary skill in the art at the time of the invention to include the above limitations as taught by ZOLFAGHARI in the systems of Goldman, 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.
Goldman does not disclose the following limitations, however Subhiksha ET AL discloses:
establishing, by a networked server, a plurality of households, wherein each household comprises at least one ride provider user and at least one ride recipient user, (Subhiksha ET AL: (Pg 1, 2nd Col., 1st Paragraph: provides carpool services by connecting parent’s group; Pg 1, 2nd Col, Paragraph 3, III. PROPOSED SYSTEM carpool group are going to be created only by parents and can add other parents whom they trust; Pg 1, 2nd Col, 5th Paragraph: A. Login/Registration Module When the user(parent)installs the application i.e., the mom and dad have to register themselves and create an account by giving the data such as their Name, Phone Number, Home Location, Email Id, Password, Number of kids along with their photos...Both the parents should upload their driver’s license which will get stored in the database [Here, parent’s group of Subhiksha is analogous to the household of the present invention since the parent group consists of the Mom, Dad and kids])); Pg. 2, Col. 1, 2ND Paragraph: C. Carpool Module (the user) the particular parent creating the carpool will be the admin of that particular carpool. He/she can add carpool members. A chat group for each carpool will be created and the carpool members can communicate using the chat option; Pg. 2, Col. 1, 3RD Paragraph: D. Event module: As the carpool is created and the members are added along with their kids name and kids’ photo...The admin only has access to choose the driver for the particular carpool event. He/she will be able to change it whenever needed), (Here, the kids and the drivers (parents added is analogous to the present invention’s ride provider user and at least one ride recipient user);
establishing, by the network server, a hive, wherein the hive represents a communication channel for a group of users, (Subhiksha et al: Pg. 2, Col. 1, 2ND Paragraph: C. Carpool Module This is the third module. In this module, the user can create carpool. The user can schedule the from and to location. He/she can schedule as many carpools they want. The user can add members using their contacts. The user must permit to access contacts, so that the parent can all the other parents for the specified carpool...A chat group for each carpool will be created and the carpool members can communicate using the chat option; ALSO SEE FIG. 1.3);
and wherein creating the hive comprises: electronically receiving, at the networked server and from a first ride recipient user device, a request to add one or more other ride recipient users to the hive, in response to the request, the networked server electronically adding a first group of one or more ride provider users to the hive, the first group of ride provider users being a subset of the ride provider users in the same household as the first ride recipient user, electronically adding the one or more other ride recipient users to the hive, and for each particular ride recipient user of the one or more other ride recipient users, electronically adding, by the server, a group of one or more ride provider users to the hive in response to the particular ride recipient user being added to the hive, the group of ride provider users being a subset of the ride provider users in the same household as the particular ride recipient user, (Subhiksha et al: SEE FIG. 1.3; ALSO SEE Pg. 2, Col. 1, 2ND Paragraph: C. Carpool Module The user can add members using their contacts. The user must permit to access contacts, so that the parent can all the other parents for the specified carpool. In order to create a new carpool, the parent should enter the carpool name, event name location and the particular parent creating the carpool will be the admin of that particular carpool. He/she can add carpool members. A chat group for each carpool will be created and the carpool members can communicate using the chat option; Pg. 2, Col. 1, 3RD Paragraph D. Event module As the carpool is created and the members are added along with their kids name and kids’ photo. The admin will be able to set events such as the from and to location, scheduling the time of the event. They can also schedule it as a repeating event and need not create a new carpool every time for the same event. The admin only has access to choose the driver for the particular carpool event. He/she will be able to change it whenever needed. So now when the event is scheduled, the date and time is synchronized with the google Calendar and all the members will get a remainder before 45 minutes of the event);
wherein each of the establishing, receiving, transmitting, and updating steps are performed by at least one server in electronic communication with user mobile devices and a database storing ride and user data, (Subhiksha et al: Pg. 2, 2nd Col., Paragraph 1: V.IMPLEMENTATION Android Studio is the official integrated development environment for Google’s Android operating system built on Jetbrains’ IntelliJ IDEA software and designed specifically for Android development);
at least one member of the hive that is also a member of the household of at least one ride recipient user other than the particular authorized driver; or wherein each group of users comprises a plurality of ride provider users associated with a plurality of independent households, wherein each ride provider user is in a same household as one or more of a plurality of ride recipient users, (Subhiksha et al: Col, Paragraph 3, III. PROPOSED SYSTEM carpool group are going to be created only by parents and can add other parents whom they trust; Pg 1, 2nd Col, 5th Paragraph: A. Login/Registration Module When the user(parent)installs the application i.e., the mom and dad have to register themselves and create an account by giving the data such as their Name, Phone Number, Home Location, Email Id, Password, Number of kids along with their photos...Both the parents should upload their driver’s license which will get stored in the database. (Here, there are a plurality of kids that are included and represent at least one member other than the parent who is the authorized driver).
It would have been obvious to one of ordinary skill in the art at the time of the invention to include the above limitations as taught by Subhiksha et al in the systems of Goldman, 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.
As per claim 2, Goldman discloses:
wherein the communication channel comprises a messaging interface that enables real-time chat functionality between members of the communication channel, ((93) One embodiment uses multiple communication channels in combination. For example, the system may utilize email, text messaging). As per claim 3, Goldman discloses:
wherein the ride recipient users comprise minor users, and wherein the ride provider users comprise adults affiliated with at least one of the minors, ((56) In some embodiments, it is possible for a parent to have multiple children in two teams in the same league. In some embodiments, the system is able to optimize storage and management of parent/family specific data that is the same for both athletes, e.g. contact, photos, insurance, waivers, and so on. Features and applications that are improved by this structure may include: never forget a face, carpool, registration, contact management, uniform purchasing, and so forth).
As per claim 5, Goldman discloses:
wherein each ride recipient user is able to invite additional ride recipient users to join the hive, and wherein addition of a new ride recipient user to the hive results in addition of at least one ride provider user associated with the new ride recipient user to the hive, ((22) Continuing in block 230, the system identifies one or more roles to associate with the created user record, wherein each role corresponds to one or more rights of the user for using the platform. The user may specify roles manually or the system may infer one or more roles based on sign up information (such as information provided in an invitation to the user). For example, a coach may send sign up invitations to each player on a team and the system may associate a player role with each invited player when the player registers with the system. Other users, such as parents, may identify their roles by identifying one or more children of which they are the parents. The system may provide a subsequent confirmation process for confirming roles, such as sending an email to the coach to confirm added players. ALSO SEE Claim 14. The system of claim 10 wherein the registration component is further configured to create one or more invitations for inviting new users to use the system).
As per claim 6, Goldman discloses:
wherein each ride provider user is able to invite additional ride provider users and affiliated ride recipient users to join the hive, ((22) Continuing in block 230, the system identifies one or more roles to associate with the created user record, wherein each role corresponds to one or more rights of the user for using the platform. The user may specify roles manually or the system may infer one or more roles based on sign up information (such as information provided in an invitation to the user). For example, a coach may send sign up invitations to each player on a team and the system may associate a player role with each invited player when the player registers with the system. Other users, such as parents, may identify their roles by identifying one or more children of which they are the parents. The system may provide a subsequent confirmation process for confirming roles, such as sending an email to the coach to confirm added players).
As per claim 8, this claim recites limitations similar to those disclosed in independent claim 1 and is therefore rejected for similar reasons.
As per claim 9, wherein the communication channel comprises a messaging interface that enables real - time chat functionality between members of the communication channel: Please see the rejection of claim 2.
As per claim 10, wherein the hive comprises one or more ride recipient users, wherein at least one of the one or more ride recipient users is a minor, and wherein the ride provider users comprise adults affiliated with at least one of the minors:
Please see the rejection of claim 3.
As per claim 12, wherein the system enables each of the ride recipient users to invite additional ride recipient users to the hive, and wherein addition of a new ride recipient user causes addition of at least one ride provider user affiliated with the new ride recipient user to the hive.
Please see the rejection of claim 5.
As per claim 13, wherein the system enables each ride provider user to invite additional ride provider users and affiliated ride recipient users to join the hive.
Please see the rejection of claim 6.
As per claim 15, this claim recites limitations similar to those of independent claim 1 and is therefore rejected for similar reasons.
As per claim 16, wherein the communication channel comprises a messaging interface that enables real - time chat functionality between members of the communication channel.
Please see the rejection of claim 2.
As per claim 17, wherein the hive further comprises one or more ride recipient users, wherein at least one of the ride recipient users is a minor, and wherein the ride provider users comprise adults affiliated with at least one of the minors.
Please see the rejection of claim 3.
As per claim 19, wherein each of the ride recipient users is able to invite additional ride recipient users to the hive, and wherein addition of a new ride recipient user causes addition of an affiliated ride provider user to the hive.
Please see the rejection of claim 5.
As per claim 20, wherein each ride provider user is able to invite additional ride provider users and affiliated ride recipient users to join the communication channel.
Please see the rejection of claim 6.
Claim(s) 4, 7, 11, 14, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goldman et al (US 9087320 B2), and further in view of ZOLFAGHARI (CA 3232345 A1), and further in view of Subhiksha et al, and further in view of MAGUIRE (AU 2014235404 A1).
As per claim 4, Goldman et al does not disclose:
wherein the communication channel restricts membership in the hive to permit a ride provider user only while the ride provider user is authorized to provide rides to at least one ride recipient user in the hive. However, MAGUIRE discloses: ([6] A brand-new device being introduced into the user's device cloud may take advantage of proximity to devices already registered as being associated with the user to jump-start customization of the user's experience with the device using social-networking information. In addition, when a guest enters a PND user's home, the guest's PND will attempt to establish a peer-to- peer connection with one of the user's devices in the device cloud. The guest may be authenticated in accordance with social graph information and other social-networking information (e.g., first-degree friends may automatically be authenticated to access and use the user's devices). Such access may be granted/restricted according to any property or attribute associated with an element of the user's social graph (e.g., only allowing access to other social-network users in a designated "Close Friends" group to be automatically authenticated upon entering the user's home).
It would have been obvious to one of ordinary skill in the art at the time of the invention to include the above limitations as taught by MAGUIRE in the systems of Goldman, 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.
As per claim 7, Goldman et al does not disclose:
further comprising: tracking location of the particular authorized driver during provision of the ride, wherein tracking location of the particular authorized driver comprises real-time location tracking of the particular authorized driver and one or more ride recipient users during the ride.
However, MAGUIRE discloses: ([77] For example, a toddler's or puppy's PND may be configured so that the PND acts as a tracking device that notifies devices in the home as the PND approaches).
It would have been obvious to one of ordinary skill in the art at the time of the invention to include the above limitations as taught by MAGUIRE in the systems of Goldman, 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.
As per claim 11, wherein the communication channel restricts membership of ride provider users to only users who are authorized to give rides to at least one of the ride recipient users.
Please see the rejection of claim 4.
As per claim 14, a tracking module configured to monitor real-time location of vehicles providing rides, wherein the tracking module performs real-time location tracking of an authorized driver and one or more ride recipient users during the ride. Please see the rejection of claim 7.
As per claim 18, wherein the communication channel restricts membership of ride provider users in the hive to only ride provider users who are authorized to give rides to at least one ride recipient user in the hive. Please see the rejection of claim 4.
Response to Arguments
Applicant's arguments filed 10/20/25 have been fully considered but they are not persuasive.
With regard to the 101 rejection, Applicant respectfully traverses this rejection, and argues that the present invention is rooted in technology and provides a technical solution by addressing the technical problem of efficiently and securely coordinating multi-household carpools using real-time, automated networked communication. However, Examiner respectfully disagrees. It is important to keep in mind that an improvement in the abstract idea itself is not an improvement in technology. For example, in Trading Technologies Int’l v. IBG, 921 F.3d 1084, 1093-94, 2019 USPQ2d 138290 (Fed. Cir. 2019), the court determined that the claimed user interface simply provided a trader with more information to facilitate market trades, which improved the business process of market trading but did not improve computers or technology. Here, the alleged improvements are not to a technology or technical field but instead to electronically manage the creation and maintenance of households, hives, and user role, which is an improvement to the coordination of carpools among households, which falls under certain method of organizing human activity.
Furthermore, Applicant argues that the claims are not directed towards “Mental Processes” and argues that the specification describes the invention as a networked, real-time carpool management system. However, as now recited in the Office Action, the claims are directed towards “Certain Methods of Organizing Human Activity” since the steps of the claims recite human interactions, managing relationships and coordinating transportation. The claims recite the establishments of households, creation of hives, associating ride providers and recipients, receiving ride requests, sending ride requests to drivers, getting acceptance and updating ride status, which are no more than managing interactions between popple, organizing and processing information and fundamental economic or business practices.
Applicant further argues that claims recite significantly more than the abstract idea. However, Examiner respectfully disagrees. The claims at hand do not disclose significantly more since the server of the claims merely disclose electronically receiving, adding, associating, transmitting and updating, which are generic operations. There is no technical improvement to the server, the mobile communication networks, the data structures, routing, ride-matching or privacy/authentication. In fact, the “hive” is merely a conceptual user group and the additional elements are routine, conventional activity implemented on generic computers.
Applicant further argues that the precedent supports eligibility where the claims are “Technologically rooted solutions”, and uses DDR Holdings, McRO and Bascom to back up his argument. However, Examiner respectfully disagrees.
With respect to DDR Holdings, the claims at issue do not require an arguably inventive device or technique, unlike the claims at issue in DDR Holdings. The use of generic computer elements like a microprocessor or user interface do not alone transform an otherwise abstract idea into patent-eligible subject matter. (See DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1256 (Fed. Cir. 2014)). Furthermore, to the extent that FairWarning suggests that its claimed invention recites a technological advance relating to accessing and combining disparate information sources, its claims do not recite any such improvement. Rather, the claimed invention is directed to the broad concept of coordinating transportation. The claims here do not propose a solution or overcome a problem “specifically arising in the realm of computer [technology].” DDR Holdings, 773 F.3d at 1257. At most, the claims require that these processes be executed on a generic computer.
With reference to McRO, the claimed rules in McRO transformed a traditionally subjective process performed by humans into a mathematically automated process executed on computers. The human process and computer process in McRO produced a similar result but did so in fundamentally different ways. It was the incorporation of the claimed rules, not the use of the computer that improved the existing technological process by allowing the automation of further tasks. In contrast, the present invention are like FairWarning’s claims. The Court found that FairWarning’s claims did not provide improved rules and “merely implement an old practice in a new environment. Also, like FairWarning’s claims, the present claims are not like the patentable claims in Enfish, which provided a specific improvement to the way computers operate, not an abstract idea implemented on a computer. Although the present invention is purported to improve the coordination of transportation, this “improvement” came from the capabilities of a general-purpose computer, not from the patented method itself. The claims are therefore abstract and do not represent “significantly more”.
With reference to Bascom, the ordered combination of the claims is being used to perform steps that a human can do. Unlike Bascom, the present claims are using conventional, known elements as a combination to affect a particular change. The present system is therefore functioning like any know server, through receiving, storing, processing, and outputting, (Fairwarning).
Applicant’s arguments, see arguments/remarks, filed 10/20/25, with respect to the rejection(s) of claim(s) 1-3, 5, 6, 8-10, 12, 13, 15, 16, 17, 19, 20, under 35 U.S.C. 103 as being unpatentable over Goldman et al (US 9087320 B2), and further in view of ZOLFAGHARI (CA 3232345 A1), have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made further in view of and further in view of Subhiksha et al.
Similarly, Claim(s)4, 7,11, 14, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goldman et al (US 9087320 B2), and further in view of ZOLFAGHARI (CA 3232345 A1), and further in view of and further in view of Subhiksha et al, and further in view of MAGUIRE (AU 2014235404 A1).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Akiba Robinson whose telephone number is 571-272-6734 and email is Akiba.Robinsonboyce@USPTO.gov. The examiner can normally be reached on Monday-Thursday 6:30am-4:30pm.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner's supervisor, Resha Desai can be reached on 571-270-7792. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system, Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (I N USA OR CANADA) or 571-272-1000.
Any inquiry of a general nature or relating to the status of this application or proceeding should be directed to the receptionist whose telephone number is (703) 305-3900.
November 20, 2025
/AKIBA K ROBINSON/Primary Examiner, Art Unit 3628