DETAILED ACTION
Notices to Applicant
This communication is a non-final rejection. Claims 19-31, as filed 9/11/2025, are currently pending and have been considered below.
Priority is generally acknowledged as shown on the filing receipt with the earliest filing date being 08/01/2011.
The present application is being examined under the pre-AIA first to invent provisions.
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 19-31 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1
The claim(s) recite(s) subject matter within a statutory category as a process, machine, and/or article of manufacture which recite:
A method of processing data associated with a portable infusion device, comprising:
establishing a connection over a network between a network data manager and a user device storing medical data relating to treatment of a user with a portable infusion device; (additional element – generally applying the abstract idea with a computer)
verifying at the network data manager that the portable infusion device is associated with a user account; (abstract idea – mental process analogous to what a human could do when thinking about whether a person is able to view data consistent with privacy rules)
receiving at the network data manager a data upload from the user device; (additional element – generally applying the abstract idea with a computer; insignificant extra-solution activity, mere data-gathering)
identifying duplicative and non-duplicative data in the data upload; (abstract idea – mental process, data comparison)
processing the non-duplicative data into a format for use by the network data manager; (abstract idea – mental process analogous to what a human could do when reviewing two records and consolidating or reduplicating them)
associating the processed data with the user account; (abstract idea – mental process, data organization) and
storing the processed data in a database for selective retrieval by the network data manager in response to a request from an authorized user associated with the user account (additional element – generally applying the abstract idea with a computer; insignificant extra-solution activity, storing data in a database).
20. The method of claim 19, further comprising: receiving a request at the network data manager for access to data associated with the user account; and providing access to the data in response to the request. (abstract idea, certain methods of organizing human activity; merely applying the abstract idea with a computer)
21. The method of claim 20, wherein the request includes an access requestor identifier, and access is provided to the data in response to the request only if the access requestor identifier is identified in the user account as having access to the data. (abstract idea, certain methods of organizing human activity and mental process)
22. The method of claim 20, wherein providing access to the data in response to the request includes generating a report for display on a user device. (abstract idea--mental process because a human can produce a report with pen and paper; merely applying the abstract idea with a computer)
23. The method of claim 19, wherein the connection between the network data manager and the user device is a wireless connection. (merely applying the abstract idea with a computer)
24. The method of claim 19, wherein the user device is a mobile computing device and further comprising receiving data from the portable infusion device at the mobile computing device. (merely applying the abstract idea with a computer)
25. The method of claim 19, further comprising automatically receiving data uploads at the network data manager from the user device at regular intervals. (merely applying the abstract idea with a computer)
26. The method of claim 19, further comprising enabling an authorized healthcare professional to access the data in the database. (abstract idea, certain methods of organizing human activity and mental process)
27. The method of claim 26, further comprising receiving a request to add a healthcare professional as an authorized healthcare professional for the user account. (abstract idea, certain methods of organizing human activity)
28. The method of claim 19, further comprising transmitting a software update to the user device. (merely applying the abstract idea with a computer)
29. The method of claim 19, wherein processing the non-duplicative data into a format for use by the network data manager includes converting the non-duplicative data from a first format to a second format. (abstract idea, certain methods of organizing human activity and mental process)
30. The method of claim 29, wherein converting the non-duplicative data from the first format to the second format includes converting the data from a text format to an XML format. (abstract idea-- mental process because a human can write XML with pen and paper)
31. (New) The method of claim 19, further comprising transmitting a confirmation to the user device when the data upload is complete. (merely applying the abstract idea with a computer)
Step 2A Prong One
The broadest reasonable interpretation of these steps includes mental processing because “identifying duplicative and non-duplicative data” is a data comparison that a person could do mentally or with pen and paper and “associating the processed data with the user account” is a data organization technique that could be performed mentally or with pen and paper. The italicized limitations above are generally able to be performed mentally or with pen and paper. These limitations further amount to certain methods of organizing human activity, namely, data management and recordkeeping.
Dependent claims recite additional subject matter which further narrows or defines the abstract idea embodied in the claims as shown above.
Step 2A Prong Two
This judicial exception is not integrated into a practical application. In particular, the additional elements do not integrate the abstract idea into a practical application, other than the abstract idea per se, because the additional elements:
amount to mere instructions to apply an exception. For example, using a network data manager to receive, process, and store data amounts to invoking computers as a tool to perform the abstract idea, see applicant’s specification [0082]: “The features described above may be implemented in a wide variety of electronic devices”), see MPEP 2106.05(f))
add insignificant extra-solution activity to the abstract idea. For example, receiving a data upload from the user device amounts to mere data gathering, the data being related to treatment of a user with a portable infusion device amounts to selecting a particular data source or type of data to be manipulated, see MPEP 2106.05(g))
Dependent claims recite additional subject matter which amount to limitations consistent with the additional elements in the independent claims. For example, claim 22 adds the display of a report which amounts to merely applying the abstract idea with a general-purpose computer. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation and do not impose a meaningful limit to integrate the abstract idea into a practical application.
Step 2B
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to discussion of integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply an exception, add insignificant extra-solution activity to the abstract idea, and generally link the abstract idea to a particular technological environment or field of use. Additionally, the additional limitations, other than the abstract idea per se amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields. For example, establishing a connection of a network amounts to receiving or transmitting data over a network, Symantec, MPEP 2106.05(d)(II)(i), performing repetitive calculations, Flook, MPEP 2106.05(d)(II)(ii), electronic recordkeeping, Alice Corp., MPEP 2106.05(d)(II)(iii), and/or storing and retrieving information in memory, Versata Dev. Group, MPEP 2106.05(d)(II)(iv).
Dependent claims recite additional subject matter which, as discussed above with respect to integration of the abstract idea into a practical application, amount to invoking computers as a tool to perform the abstract idea. Dependent claims recite additional subject matter which amount to limitations consistent with the additional elements in the independent claims. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 19-31 are rejected under 35 U.S.C. 103 as being unpatentable over Cohen (US20060031094A1) in view of Prahlad (US20100332456A1).
Regarding claim 19, Cohen discloses: A method of processing data associated with a portable infusion device (“In an example in which the subject support device is an infusion pump, various pump settings may be communicated to the subject-side computer or infusion pump, for setting pump parameters such as, but not limited to, basal rate, bolus amount, infusion start or stop times or dates, or the like,” [0066]), comprising:
--establishing a connection over a network between a network data manager and a user device storing medical data relating to treatment of a user with a portable infusion device (“Users may communicate with the medical data management system over the Internet, for example, using a conventional personal computer … Subject-users or healthcare provider-users may connect subject support devices (such as infusion pumps, meters, biological sensors, pacemakers, other electronic cardiactric aids or the like) to their user-side computers, for communicating information between the subject support devices and the medical data management system. In this manner, the system may collect and manage data from at least one user (and, in more comprehensive embodiments, from a plurality of users) and provide a number of services individually or inter-related to each other,” [0008]);
--verifying at the network data manager that the portable infusion device is associated with a user account (“Verification of the information and password may be carried out by the system 16, in any suitable manner, including, but not limited to, comparing the received password with a pre-stored password corresponding to the user identification information received from the user. Thus, for example, the database layer 28 in system 16 may include or employ a secure storage of a table (or other format) of user identification information with corresponding passwords, to allow the system to perform a table look-up (or other suitable retrieval) of a password that corresponds to user identification information received from a given use,” [0079]; “Such preambles or other portions of the received data may further include device serial numbers or other identification information that may be used for validating the authenticity of the received information. In such embodiments, the system 16 may compare received identification information with pre-stored information to evaluate whether the received information is from a valid source,” [0052]);
--receiving at the network data manager a data upload from the user device (“allow a subject-user to couple one or more subject support devices 12 to a subject-side computer 14 connected to the system 16 through the Internet, while a healthcare provider simultaneously accesses information from the subject support device(s) 12 and/or the subject-side computer 14, through an Internet connection to the system 16,” [0128]);
…
--processing the non-duplicative data into a format for use by the network data manager (“The data-parsing layer 26 is responsible for validating the integrity of device data received and for inputting it correctly into a database. A cyclic redundancy check CRC process for checking the integrity of the received data may be employed,” [0052]);
--associating the processed data with the user account (“As represented by box 72, the medical data management system 16 may provide an acknowledgment message back to the subject-side computer, for example, upon a successful receipt of information to a system 16 server and/or storage of the information in a database section established for the subject-user,” [0089]); and
--storing the processed data in a database for selective retrieval by the network data manager in response to a request from an authorized user associated with the user account (“The database layer 28 may include a centralized database repository that is responsible for warehousing and archiving stored data in an organized format for later access, and retrieval,” [0053]; “providing controlled access to stored medical data for authorized users over the communication network” claim 2).
Cohen discloses reconciling duplicative data in [0057] but does not expressly state that this occurs during the upload process. Prahlad teaches: identifying duplicative and non-duplicative data in the data upload (deduplication module 299 performs “a data object identification component 410, an identifier generation component 420, an identifier comparison component 425, and a criteria evaluation component 430… to determine if the files or data objects contain the same data” in [0142]).
It would have been obvious to one of ordinary skill in the art before the date of invention to expand Cohen’s diabetic patient data management framework to include Prahlad’s deduplication techniques because “deduplicating data before sending it can conserve time and bandwidth, and storage resources at the cloud storage site (which may charge based on amount of data stored.)” Prahlad [0149].
Regarding claim 20, Cohen discloses: receiving a request at the network data manager for access to data associated with the user account; and providing access to the data in response to the request (“providing controlled access to stored medical data for authorized users over the communication network” claim 2; “, electronic copies of such prescriptions or other records may be stored in the system database 29, for access by an authorized user,” [0149]).
Regarding claim 21, Cohen discloses: wherein the request includes an access requestor identifier, and access is provided to the data in response to the request only if the access requestor identifier is identified in the user account as having access to the data (“The database layer 28 may be configured to limit access of each user to types of information pre-authorized for that user. For example, a subject may be allowed access to his or her individual medical information (with individual identifiers) stored by the database layer 28, but not allowed access to other subject's individual medical information (with individual identifiers). Similarly, a subject's authorized healthcare provider or payor entity may be provided access to some or all of the subject's individual medical information (with individual identifiers) stored by the database layer 28, but not allowed access to another individual's personal information. Also, an operator or administrator-user (on computer 24) may be provided access to some or all subject information, depending upon the role of the operator or administrator,” [0059]).
Regarding claim 22, Cohen discloses: wherein providing access to the data in response to the request includes generating a report for display on a user device (“subject or a subject's healthcare provider may readily access formatted reports of information regarding the subject's condition, historical condition, the subject support device operation or condition, or the like, or similar information regarding one or more defined groups of subjects. The reports may be formatted in various pre-defined formats provided by the system,” [0010]).
Regarding claim 23, Cohen discloses: wherein the connection between the network data manager and the user device is a wireless connection (“the interface may comprise a wireless interface, such as an RF link, an optical link, a magnetic link or other suitable communication links. In this manner, an infusion pump may store information received from a sensor or meter over a period of time and, upon coupling the infusion pump to the network (as described herein), the stored information may be communicated to a system 16 server,” [0036]).
Regarding claim 24, Cohen discloses: wherein the user device is a mobile computing device and further comprising receiving data from the portable infusion device at the mobile computing device (“a personal digital assistant (PDA), a mobile telephone, a pager, a dedicated medical communication device, or the like. Depending upon the embodiment and environment of use, the computers or other network devices 14, 18, 20 and 22 may include or otherwise be associated with a user input device (such as, but not limited to, a keyboard, mouse, touch screen, optical input device, or the like) and a display device (such as, but not limited to a cathode-ray tube monitor, an LCD display, an LED display, a plasma display or the like),” [0040]).
Regarding claim 25, Cohen discloses: automatically receiving data uploads at the network data manager from the user device at regular intervals (“download data into a system database regularly, so that the subject's updated data (including subject support device data) may be readily available to the subject's healthcare provider or to the subject for retrieval and analysis,” [0190]).
Regarding claim 26, Cohen discloses: enabling an authorized healthcare professional to access the data in the database (“healthcare providers and subjects may readily store and later access medical information relating to the subjects, for example, to analyze historical information regarding a subject's biological condition, operation of the subject support device, treatment, treatment results, personal habits, or the like,” [0009]).
Regarding claim 27, Cohen discloses: receiving a request to add a healthcare professional as an authorized healthcare professional for the user account (“Each subject-user may designate one or more healthcare provider for connection to the system 10 through one or more respective healthcare provider computers 20, for example, to access the subject's information stored in the medical data management system 16. In this manner, a subject may designate the subject's primary physician for connection to the system 10 as a healthcare provider-user for the subject,” [0112]).
Regarding claim 28, Cohen discloses: transmitting a software update to the user device (“providing a mechanism to update user software, provide new software or new generations/versions of a given software, or provide new or revised program data automatically (or by user request). Thus, users will be more likely to have the most recent, updated versions of software, resources or data available on the system,” [0018]).
Regarding claim 29, Cohen does not expressly disclose but Prahlad further teaches: wherein processing the non-duplicative data into a format for use by the network data manager includes converting the non-duplicative data from a first format to a second format (“one or more parsers 2650 may be consulted to migrate data from one or more document types (e.g., 2660 and 2670) to an XML or other common format,” [0256]; normalizing format in [0121]).
It would have been obvious to one of ordinary skill in the art before the date of invention to expand Cohen’s diabetic patient data management framework with Prahlad’s deduplication workflow to further include Prahlad’s data formatting into a “common format” because this would allow the system to function with patient devices using diverse data formats (see Prahlad [0121] for the benefit of using generic formats).
Additionally, it can be seen that each element is taught by either Cohen or Prahlad. The data format conversion of Prahlad does not affect the normal functioning of the elements of the claim which are taught by Cohen and Prahlad such as the infusion pump data management of Cohen and the deduplication of Prahlad. Because the elements do not affect the normal functioning of each other, the results of their combination would have been predictable. Therefore, before the effective filing date of the claimed invention, it would have been obvious to combine the teachings of Prahlad with the teachings of Cohen since the result is merely a combination of old elements, and, since the elements do not affect the normal functioning of each other, the results of the combination would have been predictable.
Regarding claim 30, Cohen does not expressly disclose but Prahlad further teaches: wherein converting the non-duplicative data from the first format to the second format includes converting the data from a text format to an XML format (“one or more parsers 2650 may be consulted to migrate data from one or more document types (e.g., 2660 and 2670) to an XML or other common format,” [0256]).
The motivation to combine is the same as in claim 29.
Regarding claim 31, Cohen discloses: transmitting a confirmation to the user device when the data upload is complete (“As represented by box 72, the medical data management system 16 may provide an acknowledgment message back to the subject-side computer, for example, upon a successful receipt of information to a system 16 server and/or storage of the information in a database section established for the subject-user,” [0089]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Moberg (20070255250) discloses a handheld device that enables control of an infusion device (“Command display controller 138 is preferably realized as a handheld monitor/controller device that, although physically separate from infusion pump 128, enables the user to monitor and control the operation of infusion pump 128. This allows the user to operate infusion pump 128 without physically handling the device,” [0048]).
Dicks (20080097908) discloses formatting messages transmitted to a medical data server as XML in [0061].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA BLANCHETTE whose telephone number is (571)272-2299. The examiner can normally be reached on Monday - Thursday 7:30AM - 6:00PM, EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shahid Merchant, can be reached on (571) 270-1360. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JOSHUA B BLANCHETTE/Primary Examiner, Art Unit 3624